1 

i 

r 

AO-A104  688  BOM  CORP  ALBUQUERQUE  NH 

THEATER  NUCLEAR  FORCE  SURVIVABILITY t 
DEC  80  T  J  ANDREWS*  D  R  MORROW*  H  J 
UNCLASSIFIED  B0M/TAC-80-619-TR  DNA- 

SECURITY  AND  SAFETY 
TAUSCH  DNA001-S0 

5347F-1 

F/6  15/7 
INSTRU— ETCCU 
-C-0083 

NL 

k 

1  OF  2 

■ 

i* 

I 

I 

Hi 

0 

WTT - 

1 

A 

ft. 

4* 

*r 

M  l 

f 

1 

H 

i» 

i 

i 

a 

1 

i'l  1 

1 

fl 

w* 

r  ' 

*  i  *  i 
Hill 

\sTi 

| 

A 

ft. 

/a 

1 

K 

n 

K 

$ 

lip 

if* 

n*’ 

1^ 

■■ 

Ml 

1MI 

■ _ 

AD  A1 046  8  8 


! 


r?  js  .m 


DNA/5347F1 


JH EATER  gUCLEAR  /ORCE  SURVIVABILITY, 

SECURITY  AND  SAFETY  INSTRUMENTATION  . 

/ 

Volume  I— Engineering  Development  Phase— Fiscal  Year  1980 , 


L 


The  BDM  Corporation  ' 

P.O.  Box  9274 

Albuquerque,  New  Mexico  87119 


(  31  DecMflHHNijlBed  , 

_ _ 


y  Final  F^epert 


14  Dec 


79-31 


Dec 


\ 


■  x  '  ' r' 


CONTRACT  No/DNA  pp1-80-C-0p83 


-v  - 


/ 

i 


APPROVED  FOR  PUBLIC  RELEASE; 
DISTRIBUTION  UNLIMITED. 

T.  J.  /Andrews  D.  R.  /Morrow  H.  J.  /Tausch 
N.  P.  /Hochhausler 
M.  A.  /Ondrik 


A 


THIS  WORK  SPONSORED  BY  THE  DEFENSE  NUCLEAR  AGENCY 
UNDER  RDT&E  RMSS  CODE  B390080465  A99(S|A><^30206  H2590D. 


Prepared  for 
Director 

DEFENSE  NUCLEAR  AGENCY 
Washington,  D.  C.  20305 

i 


I 


Destroy  this  report  when  it  is  no  longer 
needed.  Do  not  return  to  sender. 

PLEASE  NOTIFY  THE  DEFENSE  NUCLEAR  AGENCY, 
ATTN:  STTI ,  WASHINGTON,  D.C.  20305,  IF 
YOUR  ADDRESS  IS  INCORRECT,  IF  YOU  WISH  TO 
BE  DELETED  FROM  THE  DISTRIBUTION  LIST,  OR 
IF  THE  ADDRESSEE  IS  NO  LONGER  EMPLOYED  BY 
YOUR  ORGANIZATION. 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  RAPE  (WlM  Omm  EkwW) 


|  REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

y  RECIPIENT'S  catalog  number 

«.  TITLE  (M  SuAIHI.J 

THEATER  NUCLEAR  FORCE  SURVIVABILITY,  SECURITY 

AND  SAFETY  INSTRUMENTATION 

Volume  I— Engineering  Development  Phase- 
Fiscal  Year  1980 

j.  type  of  report  a  period  covcnfd 

Final  Report  for  Period 

14  Dec  79—31  Dec  80 

9.  PERFORMING  ORG.  REPORT  NUMBER 

BDM/TAC-8Q-61  9-TR  ^ _ 

T.  AUTHOR?.) 

T.  J.  Andrews  N.  P.  Hochhausler  D.  W.  Homiak 

D.  R.  Morrow  M.  A.  Cndrik  G.  E.  Pax 

H.  J.  Tausch  C.  E.  Wold 

a.  contract  or  grant  numbers*; 

DNA  001 -80-C-0083 

t.  performing  organization  name  ano  address 

The  BDM  Corporation 

P.0.  Box  9274 

Albuquerque.  New  Mexico  87119 

10.  PROGRAM  ELEMENT.  PROJECT.  TASK 
AREA  A  PORK  UNIT  NUMBERS 

Subtask  A99QAXFC302-06 

II.  CONTROLLING  OFFICE  name  ano  address 

Director 

Defense  Nuclear  Agency 

Washington,  D.C.  20305 

12.  REPORT  DATE 

31  December  1980 

IS.  NUMBER  OP  PAGES 

114 

14.  MONITORING  AGENCY  name  a  AOORESSflf  <U Karan!  Ir mm  Cmurolllna  Olllcm) 

19.  SECURITY  CLASS.  (oi  thia  report ) 

UNCLASSIFIED 

IS..  OECLASSl  FICATIOM/ DOWNGRADING 
SCHEDULE  N/A 

t«.  distribution  statement  (*t  *<•  R*r*rt) 

Approved  for  public  release;  distribution  unlimited. 

•  7.  DISTRIRuTION  STATEMENT  (ml  Mm  atamcl  wand  In  Fl.cJt  20,  II  <fl Karan!  Irmm  Rap on) 

IS.  SUPPLEMENTARY  notes 

THIS  WORK  SPONSORED  BY  THE  DEFENSE  NUCLEAR  AGENCY  UNDER  RDT&E 

RMSS  CODE  B390080465  A99QAXFC30206  H2590D. 

19.  nev  WORDS  (Cantlmt*  on  rtmit  mil*  it  nmcmmmmy  Identity  by  Woe*  mmbm) 

Theater  Nuclear  Force  Survivability,  Security,  and  Safety 

Force-on-Force 

Free-Play 

Real-Time  Casualty  Assessment 

Microprocessors 

I9i  ABSTRACT  (Cut  In wo  «  r«*vM  W*  If  ooooiiwy  mmiloailtr  br  btf*  w>yj 

This  report  presents  the  status  of  tne  engineering  development  phase  of  the 
TNFS3  Instrumentation  Development  effort.  Evaluation  of  TNFS3  technologies, 
hardware,  and  concepts  required  field  testing  in  both  controlled  test  environ¬ 
ments  and  simulated  tactical  environments.  Free-play,  force-on-force  testing, 
and  real-time  casualty  assessment  provide  the  two-sided,  free-flowing  opera¬ 
tional  scenarios  necessary  to  determine  successfully  the  resolution  of  the 
majority  of  the  TNFS3  issues. 

- a - - 

— —  ■  A  —  ■ 

00  ,:2Tn  T473  «o»tio»  of  i  NOV «s is ^molkti  UNCLASSIFIED 


SCCUfflTY  CLARIFICATION  OP  TMVf  PAOt  (Wkm  Dm*  tmmm*) 


PREFACE 


This  report  was  prepared  by  The  BDM  Corporation,  Technology  Applica¬ 
tions  Center,  1801  Randolph  Road  S.E.,  Albuquerque,  New  Mexico  87106 
under  the  Defense  Nuclear  Agency  contract  DNA001-80-C-0083.  Captain  S. 
W.  Achromowicz  is  the  Contracting  Officer's  Representative. 

This  report  presents  the  status  of  the  Engineering  Development  phase 
for  the  TNFS3  Instrumentation  Development  effort.  This  instrumentation 
is  needed  to  satisfy  the  test  analysis  and  evaluation  requirements  on 
force-on- force,  free-play  testing  of  the  TNFS3  using  real-time  casualty 
assessment.  The  instrumentation  design  philosophy  centered  around  a 
system  that  is  to  be  modular,  flexible,  and  expandable.  The  instrumen¬ 
tation  will  be  portable,  will  not  require  extensive  field  support,  and  in 
some  cases  will  be  secure  from  outside  monitoring.  Existing,  off-the- 
shelf  technology  is  being  used  to  minimize  development  risk. 

The  instrumentation  system  consists  of  three  basic  elements.  The 
master  station  performs  the  operations  and  maintenance,  calibration,  test 
control,  and  data  quick-look  tasks.  The  RF  communications  system  allows 
for  two-way  communications  from  the  master  station  via  repeaters  to  the 
players,  and  will  evolve  into  an  accurate  transponder  position  location 
subsystem.  The  player  instrumentation  contains  a  microcomputer  and  will 
be  capable  of  totally  decentralized  operations.  It  will  perform  the 
functions  of  position  location,  weapon  simulation  (weapon  and  target 
sensors),  player  cueing,  data  logging,  RF  communications  with  the  master 
station,  and  the  computation  of  real-time  casualty  assessments. 
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SECTION  1 


EXECUTIVE  SUMMARY 

1-1  INTRODUCTION. 

The  Theater  Nuclear  Force  Survivability,  Security,  and  Safety 
(TNFS3)  Program  instrumentation  system  consists  of  several  subsystems 
working  together  in  a  coordinated  way  to  accomplish  the  real-time  data 
acquisition  and  processing  task  essential  to  the  successful  operation  of 
the  TNFS3  testing  program.  For  the  first  time,  an  instrumentation  system 
exists  which  utilizes  the  concept  of  distributed  processing  to  vastly 
simplify  both  the  hardware  and  the  software  and  at  the  same  time  meet  the 
stringent  operational  requirements  of  small-force  close-in  engagements. 

The  system  elements  which  make-up  the  instrumentation  are 

1.  The  player  pack  and  its  associated  subsystems  are  lightweight 
and  transparent  to  the  human,  providing  realistic  free-play 
force-on-force  scenarios. 

2.  The  master  station  which  provides  the  test  set-up,  command  and 
control,  real-time  monitoring,  quick-look  data  evaluation,  and 
an  operations  and  maintenance  base  for  the  field  test. 

3.  The  repeater/transponder  network  which,  if  utilized,  provides  a 
bidirectional  data  link  between  the  master  station  and  the 
individual  player  packs  and  allows  the  player  packs  to  deter¬ 
mine  their  location  within  the  test  area. 

4.  The  umpire  or  test  monitor,  an  adaptation  of  the  basic  player, 
allows  for  real-time  recording  of  events  by  expert  observers. 

1-1.1  The  Key  Element  is  the  Player  Pack. 

The  player  pack  is  the  key  element  of  the  distributed  instru¬ 
mentation  system.  Each  player  is  equipped  with  a  player  pack  and  becomes 
a  completely  autonomous  element  of  the  test.  No  command  and  control 
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element  or  central  data  processing  facility  is  required  since  each  player 
carries  all  the  computational  capability  necessary  for  his  role  in  the 
scenario.  The  same  unit  is  used  to  instrument  many  different  types  of 
players;  fixed  objects  such  as  doors,  buildings,  emplaced  weapons,  etc. 
(key  elements  in  the  test)  can  be  players  as  well  as  the  more  traditional 
humans,  vehicles,  and  aircraft.  In  addition,  the  player  pack  is  used  to 
instrument  umpires  and  observers  so  that  their  observations  are  easily 
incorporated  into  the  total  data  base.  Finally,  the  player  pack  can  be 
augmented  with  additional  capabilities  for  use  as  a  repeater/transponder 
controller  or  even  as  a  micromaster  station.  This  commonality  of  usage 
allows  considerable  reductions  in  cost  and  logistics. 

As  shown  in  Figure  1,  the  player  pack  is  ruggedized  to  with¬ 
stand  the  abuse  of  free-play  force-on-force  activities.  The  size  and 
weight  have  been  minimized  to  avoid  interference  with  normal  player 
activity,  and  the  modular  design  allows  special-function  printed  circuit 
boards  to  be  added  to  or  deleted  from  the  player  pack  as  required,  making 
the  unit  extremely  flexible. 

The  player  pack  is  basically  a  microcomputer  which  provides  all 
of  the  needed  real-time  data  processing  capability  for  a  single  player. 
Real-time  player  activity  data  are  acquired  through  pack  interfaces  with 
the  weapons  effects,  position  location,  and  RF  communications  subsystems. 
These  data  are  processed  in  real  time  by  the  player  pack,  producing  a 
record  of  a  player's  position,  fire  events,  and  real-time  casualty 
assessment.  This  record  is  stored  in  the  player  pack  and  then  unloaded 
to  the  master  station  at  the  end  of  the  test  sequence.  The  software  for 
the  player  pack  microcomputer  is  modular  for  enhanced  flexibility  and 
ease  of  use;  because  it  contains  single-player  software,  it  is  very 
simple. 

The  weapons  effects  simulator  is  provided  by  a  weapon-mounted 
bore-sighted  laser  whose  beam  of  light  simulates  the  projectile.  Pulse 
position  modulation  of  the  laser  beam  allows  data  to  be  transmitted 
between  the  firer  and  the  target.  These  data  are  received  by  detectors 
on  the  target  player  and  are  both  stored  in  and  acted  upon  by  the  player 
pack  in  real  time. 
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subsystem  to  rapidly  unload  the  data  stored  in  the  player  packs,  either 
posttest  or  during  a  test.  This  feature  is  only  usable  where  data 
security  is  not  a  problem. 

Magnetic  bubble  memories  will  be  used  in  the  player  packs  as  a 
nonvolatile  storage  medium  for  all  real-time  player-related  data.  This 
same  bubble  memory  is  also  used  to  store  the  player  pack  software, 
further  enhancing  the  flexibility  of  the  player  pack  since  the  software 
is  easily  modified.  When  the  transponder  position  location  option  is 
used,  a  player  pack  is  used  as  a  controller.  In  this  application,  data 
storage  is  not  required.  Therefore,  to  reduce  cost  an  EPROM  card 
replaces  the  bubble  memory  module. 

1-2  THE  MASTER  STATION. 

The  primary  functions  of  the  master  station  are  to  initialize 
the  players  with  player  i  dent  f f ication  numbers  prior  to  the  test 
sequence,  perform  as  a  test  controller,  accumulate  the  data  logged  in  all 
of  the  player  packs  at  the  end  of  the  test,  quickly  check  data  for 
validity,  and  produce  a  merged  event  data  tape  of  the  trial  for  later 
detailed  analysis.  The  master  station,  housed  in  a  single  8-  by  40-foot 
van  for  ease  of  mobility,  will  also  act  as  a  field  maintenance  station. 

1-3  THE  REPEATER/TRANSPONDER  NETWORK. 

Whenever  real-time  monitoring  of  player  activity  or  master 
station  command  and  control  is  desired,  the  RF  communications  subsystem 
must  be  used.  To  guarantee  full  radio  coverage,  a  series  of  repeaters  is 
used  to  propagate  the  radio  signal  into  areas  that  would  be  shadowed  if 
only  a  single  transmitter  were  used.  The  repeater  element  consists  of  a 
player  pack  transceiver,  an  amplifier,  and  a  player  pack  as  a  controller. 

When  the  highly  accurate  TNFS3  transponder  position  location 
subsystem  is  used,  it  "piggy  backs"  on  the  RF  communication  subsystem. 


i 

For  this  application,  the  repeaters  also  act  as  transponders  and,  conse¬ 
quently,  must  be  surveyed  into  place. 

1-4  THE  UMPIRE/MONITOR. 

The  use  of  umpires  is  optional,  but  they  can  provide  on-site 
human  intelligence  to  accommodate  recording  of  unconventional  events.  An 
umpire  is  equipped  with  a  standard  player  pack  to  record  data  for  later 
entry  into  the  test  data  base.  Instead  of  a  standard  weapon  simulator, 
the  umpire  carries  a  simple  laser  designator  which  is  controlled  by  the 
same  weapons  effects  simulator  used  by  the  players.  This  designator 
allows  the  umpire  to  make  administrative  kills  or  to  re-activate  a  player 
who  was  assessed  as  a  casulaty  when  he  shouldn't  have  been. 

1-5  INSTRUMENTATION  DEVELOPMENT  SUMMARY. 

The  DNA  TNFS3  Instrumentation  Development  Program  has  been  a 
highly  successful  development  and  acquisition  program.  It  is  generally 
agreed  that  the  measures  of  merit  in  system  acquisition  programs  are 
costs,  schedule,  and  achievement  of  the  specified  system  performance. 
The  development  schedule  is  shown  in  Figure  2.  It  has  been  well  docu¬ 
mented  that  in  the  past  several  decades  very  few  system  acquisitions  have 
successfully  achieved  their  predicted  measures  of  merit.  The  reasons  for 
the  poor  record  have  been  attributed  to  a  variety  of  factors  but  numerous 
studies  have  shown  that  developments  at  the  forward  edge  of  technology 
and  those  with  a  high  degree  of  Government  involvement  are  least  likely 
to  achieve  predicted  cost,  schedule,  and  performance.  In  sharp  contrast, 
the  DNA  Instrumentation  Development  Program  is  an  advanced  technology 
program  with  a  degree  of  Government  involvement  (major  system  components 
are  contracted  for  by  the  Government  and  provided  as  Government- furnished 
equipment  (GFE)  for  integration  into  the  system)  and  the  program  is: 


Instrumentation  development  pi  a 


1 .  On  Cost 


-  Unit  cost  of  the  player  unit  has  been 
reduced  to  $19,500  from  $27,000  predicted 
in  December  1978. 


2. 

On  Schedule 

-  Development  has  progressed  as  scheduled 
with  the  only  delays  being  programmed  by  DNA 

3. 

Within 

Speci fications 

-  There  has  been  no  compromising  of  the 
systems  capabilities.  Each  subsystem 
meets  or  exceeds  the  initial  design  specifi¬ 
cations. 

1-6 

SUMMARY. 

The  use  of 

distributed  processing  eliminates  catastrophic 

instrumentation  failures.  Any  failures  occur  on  a  player-by-player 
basis,  allowing  the  system  to  degrade  gracefully  and  control lably. 


Single  player  software  is  orders  of  magnitude  simpler  than 
multi-player  software.  Instead  of  a  single  copy  of  the  software  handling 
the  real-time  processing  for  many  players,  we  have  many  copies  of  the 
software  each  handling  the  processing  for  a  single  player.  This  software 
simplicity  allows  rapid  response  to  changing  test  conditions. 

The  player  autonomy  inherent  in  the  distributed  instrumentation 
facilitates  rapid  addition  and  deletion  of  players  as  test  conditions  are 
altered.  In  fact,  the  number  of  players  in  a  test  is  limited  only  by  the 
number  of  available  player  packs. 
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SECTION  2 


HISTORICAL  OVERVIEW  OF  THE  TNFS3  PROGRAM 
2-1  INTRODUCTION. 

The  Theater  Nuclear  Force  Survivability  and  Security  (TNFS2) 
program  was  initiated  in  January,  1977,  by  the  Secretary  of  Defense  as  he 
communicated  to  the  Director  of  the  Defense  Nuclear  Agency  (DNA)  his 
concern  about  the  survivability  and  security  of  the  Theater  Nuclear 
Forces  (TNF).  He  directed  DNA  to  establish 

"...a  broad  technological  program  that  will  allow  decisions  to  be 
made  on  issues  surrounding  the  survivability  and  security  without 
degradation  of  the  resultant  effectiveness  of  the  theater  nuclear 
weapons  and  their  delivery  systems..." 

DNA  was  further  directed  to  accomplish  this  objective  by 

"...utilizing,  to  the  maximum  degree  possible,  systematic  investi¬ 
gations  based  on  realistic  operational  test  data..." 

In  1979,  the  TNFS2  program  was  expanded  in  scope  to  explicitly 
include  Safety,  thus  becoming  the  Theater  Nuclear  Force  Survivability, 
Security,  and  Safety  Program  (TNFS3). 

2-2  PROGRAM  SCOPING  PHASE. 

The  scoping  phase,  which  was  performed  in  1977,  concluded  that 
"...systematic  investigations  based  on  realistic  operational  test 
data..."  required  instituting  a  testing  program  in  which  "real-time" 
performance  data  were  gathered  for  evaluating  both  the  current  surviva¬ 
bility  and  security  of  the  TNF  and  the  effectiveness  of  any  proposed 
improvements. 
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Furthermore,  the  scoping  effort  identified  the  need  for 
. . free-play,  force-on-force  test  scenarios  using  real-time  casualty 
assessment..."  as  the  primary  procedure  for  gathering  the  data  necessary 
to  validate  the  models  used  in  assessing  the  S2  posture  of  the  TNF.  In 
addition,  these  data  will  be  used  to  evaluate  both  tactics  and  training 
effectiveness.  To  maintain  realism,  tests  will  be  conducted  at  multiple 
sites  in  both  CONUS  and  in  Europe. 

Examination  of  the  issues  supplied  by  USAFE  allowed  development 
of  a  spectrum  of  test  scenarios  with  the  following  general  character¬ 
istics: 

1.  The  number  of  players  is  typically  30  to  50  with  an  occasional 
requirement  of  100. 

2.  The  typical  playing  area  is  several  hundred  meters  (300  by  300) 
with  a  maximum  area  of  2  by  2  kilometers. 

3.  Weapon  engagements  will  occur  at  very  short  ranges  (3  to  10 
meters)  as  well  as  at  longer  ranges. 

4.  The  weapon  systems  are  primarily  man-portable. 

Finally,  the  scoping  phase  concluded  that  "...some  kind  of 
instrumentation  is  required  to  gather  the  necessary  real-time  data...", 
and  furthermore,  it  must  have  the  following  functional  and  operational 
characteristics: 

1.  Affordability  --  The  instrumentation  development  and  initial 
procurement  must  not  be  significant  in  relation  to  the  total 
overall  cost  of  the  TNFS2  program. 

2.  Cost  of  Operation  --  The  set-up  time,  facilities,  and  opera¬ 
tions  personnel  costs  must  be  minimized. 

3.  Maintenance  and  Logistics  --  The  instrumentation  must  be  easily 
maintained  and  easily  transported  to  remote  test  sites  in  CONUS 
and  Europe. 


4.  Useful  Lifetime  --  The  useful  lifetime  of  the  instrumentation 

must  exceed  the  projected  5-year  duration  of  the  TNFS2  program. 

5.  Flexibility  --  The  instrumentation  must  accommodate  many  dif¬ 
ferent  player  types  (humans,  vehicles,  aircraft)  and  adapt  to 
variable  player  roles. 

6.  Operability  --  The  instrumentation  must  function  in  adverse 

weather,  hilly  forested  terrain,  and  in  both  day  and  night 
tests. 

7.  Realism  --  The  instrumentation  must  provide  realistic  weapon 

simulation  including  Real-Time  Casualty  Assessment  (RTCA)  and 
real-time  player  attrition,  especially  for  close-in  engage¬ 
ments. 

2-3  INSTRUMENTATION  STUOY  PHASE. 

The  Instrumentation  Study  effort  was  performed  in  1978  and 
developed  the  detailed  specifications  for  instrumentation  meeting  the 
requirements  identified  in  the  scoping  phase.  Furthermore,  this  effort 
was  to  identify  which  of  the  available  instrumentation  systems  would  meet 
the  TNFS2  requirements. 

2-3.1  Detailed  Specifications  Development. 

Development  of  the  detailed  specifications  requires  simul¬ 

taneous  analysis  of  how  the  instrumentation  is  to  be  used  (operational); 
what  data  are  to  be  gathered  and  how  they  will  be  used  (functional);  and 
the  financial  impact  of  the  instrumentation,  both  initial  and  recurring, 
on  the  program  (economic). 

2-3. 1.1  Operational  Requirements.  The  system  operational  requirements 
are  extracted  from  the  generalized  phraseology  of  the  scoping  phase 
document  and  all  of  these  must  be  simultaneously  assessed  for  their 
combined  impact  on  the  instrumentation  requirements. 


2-3. 1.1.1  Mobility  and  Foreign  Test  Security.  The  requirement  to  test  at 
multiple  sites  implies  that  the  instrumentation  must  be  highly  mobile. 
Many  of  the  identified  potential  test  sites  are  quite  remote.  This  means 
that  a  certain  amount  of  routine  maintenance  capability  must  be  included 
in  the  mobile  installation.  Testing  in  Europe  introduces  additional 
constraints  on  security.  Any  instrumentation  signature  must  be  uninforma¬ 
tive.  In  particular,  the  system  must  NOT  depend  for  its  operation  on  the 
telemetry  of  raw  data  from  which  weapon  lethality  or  performance  informa¬ 
tion  might  be  derived. 

2. 3.1.1. 2  Flexibility  to  Incorporate  Identified  Scenarios.  The  instru¬ 
mentation  must  be  flexible  enough  to  adapt  quickly  to  widely  varying 
scenarios;  including  rapid  changes  in  the  number  of  players,  variations 
in  player  types,  and  a  wide  range  of  weapon  types  including  those  of 
foreign  manufacture.  The  last  is  particularly  true  of  European 
scenarios. 

2-3. 1.1. 3  Life-Cycle  and  Long  Term  Growth  Potential.  Instrumentation 
life-cycle  is  highly  dependent  on  initial  loading  and  growth  potential. 
The  history  of  instrumentation  indicates  that  the  load  placed  on  it  will 
increase  rapidly  as  it  is  used.  Consequently,  the  system  must  be  able  to 
handle  all  of  the  identified  requirements  with  ease  and  have  significant 
reserve  capacity  to  handle  new  requirements  as  they  surface. 

2-3. 1.2  Functional  Requirements.  Functional  requirements  identify 
which  data  are  to  be  gathered  and  how  it  must  be  done.  The  ultimate  use 
of  these  data  and  the  operational  restrictions  placed  on  the  system  must 
be  simultaneously  accommodated. 

2-3. 1.2.1  Oata  Identity  and  Accuracy  Requirements.  Data  requirements 
and,  therefore,  the  required  data  acquisition  capabilities  of  the  instru¬ 
mentation  are  shown  in  Table  1.  These  were  determined  by  examination  of 
the  models  being  validated  and  by  the  issues  supplied  by  EUCOM  and  USAFE. 
Oata  accuracy  requirements  are  driven  by  the  specific  use  of  the  data. 
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TABLE  1.  TNFS2  DATA  REQUIREMENTS 


Datalogging  Op  to  (0  (,0,|r5  Onboard  Bulk  Storage 


The  wide  range  in  accuracies  is  a  function  of  the  specific  issue  and 
scenario,  the  size  of  the  area  involved,  the  number  and  types  of  players, 
and  the  weapons  employed. 

2-3. 1.2. 2  Real-Time  Casualty  Assessment  Requirements.  The  requirement 
for  RTCA  dictates  both  that  weapon  simulators  be  used  and  that  the 
instrumentation  include  an  element  with  the  computational  capability  to 
perform  casualty  assessments  for  all  players  in  real-time. 

The  small  number  of  players  in  the  TNFS3  scenarios  makes  accu¬ 
rate  RTCA  very  critical.  When  many  players  are  involved,  large  number 
statistics  and  random  choice  are  suitable.  When  only  a  few  players  are 
involved,  inappropriate  attrition  affects  a  sizeable  percentage  of  the 
force.  This  results  in  highly  biased  attrition  ratios  and  naccurate  con¬ 
clusions.  Small  forces  also  make  consideration  of  wounds  very  important. 
In  actual  combat  situations,  wounded  individuals  are  very  often  still 
functional,  although  their  operational  efficiency  is  reduced. 

Again,  the  small  number  of  players  requires  that  casualties  be 
removed  from  action  in  real  time.  The  alternative  results  in  "dead” 
players  continuing  to  engage,  thereby  nullifying  the  usefulness  of  any 
attrition  ratios  in  the  final  analysis. 

Detailed  analysis  of  the  critical  parameters  involved  in 
casualty  assessment  was  performed  in  the  Transportation  Safeguards  Effec¬ 
tiveness  Model  (TSEM)  Program  for  the  Department  of  Energy  in  1978.  TSEM 
concluded  that  the  following  parameters  were  qualitatively  most  important 
for  accurate  casualty  assessment: 

1 .  Range 

2.  Body  area  affected 

3.  Firer  posture 

4.  Immediately  adjacent  vertical  shielding 
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5.  8ody  armor 

6.  Weapon  type 

7.  Firing  mode  and  round  type 

8.  Firer  marksmanship 

Data  from  AMSAA  on  weapon  lethality  must  be  used  to  produce  quantita¬ 
tively  accurate  and  validated  results. 

Simulation  of  direct-fire  weapons  has  been  under  development  by 
TRADOC  for  several  years.  However,  the  TRADOC  system  is  designed  for 
training  and  relies  heavily  on  large  number  statistics  for  casualty 
assessment. 

2-3. 1.2.3  Position  Location  Requirements.  The  requirement  for  position 
location  derives  in  part  from  its  use  in  tactics  evaluation  and  movement 
analysis  and  in  part  from  the  requirement  that  the  tests  be  "free-play" 
such  that  player  movements  are  in  no  way  predetermined.  Consequently,  the 
players  must  be  tracked,  inobtrusively ,  by  the  instrumentation.  The  wide 
range  in  position  accuracy  requirements  indicates  that  more  than  one 
method  of  position  location  should  be  used  if  an  acceptable  reduction  in 
accuracy  can  result  in  a  cost  savings.  The  system  must,  however,  be 
capable  of  meeting  the  most  stringent  accuracy  requirements  when  neces¬ 
sary. 

2-3. 1.3  Economic  Requirements.  Economic  requirements  both  impact  and 
are  impacted  by  all  of  the  operational  and  functional  requirements.  This 
is  particularly  true  of  recurring  costs  which  have  a  tremendous  impact  on 
the  choice  of  technologies  used. 

2-3. 1.3.1  Initial  Acquisition  and  Development  Costs.  The  initial  acqui¬ 
sition  cost  must  be  kept  as  low  as  possible  so  that  the  bulk  of  the  total 
program  budget  can  be  devoted  to  using,  rather  than  purchasing,  the 
instrumentation. 
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2-3. 1.3.2  Recurring  Operational  Costs.  Recurring  operational  costs  must 
be  naturally  low  as  a  feature  of  the  system  design.  Recurring  costs  are 
predominantly  determined  by  the  size  of  the  skilled  staff  required  to 
operate  and  maintain  the  instrumentation  system.  To  this  end,  the  instru¬ 
mentation  must  be  simple  to  use  and  maintain.  This  implies  built-in 
initialization  and  modular  construction  to  minimize  orchestration  and 
logistics  which,  in  turn,  minimize  the  ratio  of  operators  to  players. 
Finally,  the  system  must  be  inherently  simple  in  order  to  further  reduce 
the  number  of  skilled  operators  required  to  keep  it  running  or  to  prepare 
it  for  new  scenarios. 

2*3.2  Instrumentation  Selection  Process. 

After  a  thorough  examination  of  available  hardware,  the  instru¬ 
mentation  study  concluded  that,  of  the  several  existing  fielded  instru¬ 
mentation  systems,  none  was  able  to  meet  the  combination  of  critical 
requirements  imposed  by  the  TNFS3  mode  of  operation. 

2-3. 2.1  Failure  to  Meet  Operational  Requirements.  The  instrumentation 
systems  in  use  today  were  not  conceived  with  the  intention  of  ever 
meeting  the  operational  constraints  of  the  TNFS3  program.  In  fact,  the 
state  of  the  art  in  technology  at  that  time  could  not  begin  to  address 
these  requirements.  It  is,  therefore,  not  surprising  that  these  systems 
are  unable  to  adequately  meet  the  specified  operational  requirements. 

2-3.2. 1.1  Inadequate  Mobility  and  Foreign  Test  Security.  All  existing 
systems  depend  on  a  large  central  computer  or  complex  of  computers  to 
handle  the  real-time  processing  load  of  many  players.  For  example,  the 
central  complex  at  the  U.S.  Army  Combat  Development  Experimentation 
Command  (CDEC)  consists  of  12  mid-sized  computers  linked  to  a  thirteenth, 
larger  computer  for  coordination.  Such  a  facility  is  clearly  not  mobile 
in  the  sense  required  for  TNFS3  applications.  Furthermore,  failure  of 
even  one  of  these  computers  is  catastrophic  to  the  conduct  of  a  test. 

These  "centralized"  systems  all  depend  on  telemetry  of  raw  data 
from  the  players  to  the  central  computer  for  real-time  processing. 
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Consequently,  they  all  exhibit  a  highly  informative  signature  which  makes 
them  totally  unsuitable  for  use  in  Europe  or  anywhere  else  where  eaves¬ 
dropping  may  occur.  Additionally,  a  failure  of  the  telemetry  network  is 
catastrophic  to  the  test  in  progress  in  the  same  was  as  central  computer 
failure. 

2-3.2. 1.2  Inflexibility  and  Lack  of  Growth  Potential.  Modifications  to 
the  complex  multi-player  real-time  software  is  a  lengthy  and  expensive 
process  entailing  a  great  deal  of  risk.  The  additional  staff  required  to 
make  these  modifications  with  the  responsiveness  required  for  the  TNFS3 
testing  program  would  be  prohibitive. 

Finally,  all  of  the  instrumentation  systems  in  current  use 
utilize  the  technologies  of  the  1960's  and  were  designed  to  operate  opti¬ 
mally  in  only  a  very  specific  test  environment.  Consequently,  none  is 
flexible  enough  to  adapt  quickly  and  cost  effectively  to  the  widely 
varying  requirements  and  scenarios  identified  for  TNFS3. 

2-3. 2. 2  Functional  Capabilities  Do  Not  Meet  Requirements.  The  existing 
systems  were  designed  to  do  the  best  they  could  in  acquiring  the  real¬ 
time  data  needed  for  the  specific  application  at  hand.  These  systems  are 
pressed  to  the  limit  of  the  technologies  that  were  available  at  the  time 
they  were  designed.  Addition  of  the  performance  requirements  of  TNFS3  is 
beyond  their  abi 1 ity. 

2-3. 2. 2.1  Weapon  Simulators  Do  Not  Meet  RTCA  Requirements.  Of  the 
available  weapon  simulation  systems,  all  but  one  were  designed  to  operate 
with  the  help  of  a  central  computer  and  were  designed  for  use  with  armor. 
Consequently,  they  are  overly  large  for  routine  use  by  humans.  The  one 
system  that  does  not  depend  on  a  central  computer  was  developed  by  Xerox 
for  TRADOC  (MILES)  and  is  a  fully  independent  firearms  trainina  device. 
Because  it  was  designed  specifically  for  training,  MILES  makes  absolutely 
no  engagement  data  available  for  either  real-time  or  posttrial  analysis. 
Furthermore,  the  RTCA  methodology  employed  by  MILES  is  built  into  the 
hardware  and  cannot  be  modified  to  meet  the  stringent  TNFS3  requirements. 


20 


n 

I 


All  of  these  systems  work  well  in  the  environment  for  which  they  were 
designed,  but  the  TNFS3  environment  is  sufficiently  different  to  make 
them  unusable. 

2-3. 2. 2. 2  Position  Location  Techniques  Are  Not  Suitable.  The  position 
location  techniques  employed  by  existing  systems  were  designed  to  operate 
in  conjunction  with  the  central  computer  and  to  cover  large  areas  as 
would  be  used  in  armor  exercises.  They  require  the  accurate  survey  of 
many  radio  towers  which  are  quite  expensive.  None  of  them  can  adequately 
handle  the  accuracy  requirements  in  the  small  areas  envisioned  in  the 
TNFS3  scenarios  on  a  routine  basis. 

2-3. 2. 3  Existing  Instrumentation  is  Costly.  The  acquisition  cost  of 
all  existing  systems  is  moderate  to  high  with  central  facilities  costs  in 
the  1  to  2  million  dollar  range  and  player  telemetry  units  costing 
approximately  20  to  30  thousand  dollars  each.  Equipping  these  systems 
for  mobile  operations  would  add  an  additional  500  thousand  dollars  to  the 
purchase  price. 

The  recurring  costs  of  operation  are  very  high  for  all  the 
instrumentation  systems  in  use  today.  The  central  computer  requires  a 
resident  staff  of  highly  skilled  operators  to  keep  it  operational.  The 
additional  burden  of  mobility  would  very  likely  increase  the  number  of 
operators  required,  thus  further  exacerbating  the  already  high  cost  of 
operation. 

2-4  INSTRUMENTATION  DEVELOPMENT  PHASE. 

The  Instrumentation  Development  Phase  was  initiated  to  develop 
a  new  generation  of  instrumentation  meeting  both  the  known  and  antici¬ 
pated  requirements  of  the  TNFS3  program  and  having  wide  applicability 
across  the  entire  range  of  the  OT&E  and  Joint  Test  programs  of  the  DOD. 
This  has  not  been  a  technology  development  program,  but  rather  has 
focussed  on  implementing  the  latest  proven  technologies  and  design  philo¬ 
sophies  wherever  applicable  to  best  meet  the  overall  program  objectives. 
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To  date  the  program  has  been  singularly  successful  in  meeting  all  of  the 
objectives  identified  in  the  scoping  phase:  function,  logistics,  cost, 
and  schedule. 

2-4.1  The  New  Instrumentation  Meets  All  Operational  Requirements. 

The  technology  developments  of  the  1970's  have  made  it  possible 
to  meet  the  TNFS3  operational  requirements,  not  only  as  they  are 
presently  identified  but  also  anticipating  future  requirements. 

2-4. 1.1  Mobility  and  Foreign  Test  Security.  In  order  to  meet  the 
security  requirements  of  a  European  test,  the  system  must  not  depend  for 
its  operation  on  telemetry  of  raw  data.  This  requirement  alone  estab¬ 
lishes  the  architecture  --  distributed  processing  --  of  the  entire 
system.  Use  of  this  architecture  has  been  desired  for  a  long  time  in  the 
test  and  evaluation  community,  but  has  never  before  been  technically 
feasible. 

Each  player  unit  of  the  TNFS3  instrumentation  system  performs 
all  of  the  real-time  computations  necessary  for  the  individual  it  instru¬ 
ments.  Thus  the  data  processing  load  is  "distributed"  to  all  of  the 
players  in  the  test.  All  raw  data  is  stored  in  the  player  unit  for 
posttest  analysis.  This  architecture  eliminates  the  need  for  telemetry 
of  raw  data  and  makes  the  system  usable  in  Europe.  Furthermore,  the 
real-time  software  is  greatly  simplified  since  it  only  processes  the  data 
related  to  a  single  player. 

In  order  to  meet  the  TNFS3  mobility  requirements,  the  entire 
system  is  small,  collapsable,  and  portable.  This  too  is  made  possible  by 
the  distributed  architecture;  the  large  central  computer  complex  is  no 
longer  needed.  In  its  place  is  a  "central"  minicomputer  completely 
housed  in  an  air-1 iftable  semitrailer.  This  minicomputer  provides  a 
"quick-look"  posttest  data  validation  capability  that  can  further  reduce 
the  costs  of  testing.  Player  data  can  be  validated  before  dispersing  the 
players,  thereby  saving  the  cost  of  reassembling  them  should  the  data 
prove  unusable. 
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The  central  site  can  serve  in  an  optional  command  and  control 
mode  which  exhibits  no  usable  signature.  Data  transferred  over  the  RF 
network  can  be  void  of  RTCA  and  weapons  effects  information,  but  still 
provide  a  real-time  display  of  player  activity,  should  the  test  director 
desire  it. 

2-4. 1.2  Flexibility  Is  Designed  In.  To  meet  the  flexibility  require¬ 
ments,  the  entire  system  is  highly  modular.  This  allows  easy  addition  of 
new  modules  to  add  new  functions  as  well  as  redesign  of  old  modules  to 
incorporate  new  technologies  in  accomplishing  the  same  function.  This 
structure  vastly  reduces  the  operational  logistics  and  the  associated 
costs  of  using  the  instrumentation  system  and  makes  transitions  from  one 
scenario  to  the  next  quite  straightforward. 

2-4. 1.3  Long  Life  Cycle  Is  Designed  In.  Long  life  cycle  is  a  natural 
benefit  of  the  modular  design  of  the  instrumentation.  As  requirements 
and/or  weapon  systems  evolve,  new  modules,  either  hardware  or  software, 
can  be  easily  incorporated  into  the  system  in  a  natural  uncomplicated 
way.  This  feature  makes  the  system  lifetime  virtually  unlimited.  Addi¬ 
tionally,  the  player  pack  microcomputer  has  been  designed  to  have  nearly 
a  100  percent  growth  capability  in  terms  of  loading.  This  additional 
capability  will  allow  it  to  handle  the  additional  requirements  antici¬ 
pated  in  the  future. 

2-4.2  All  Functional  Requirements  Are  Met  or  Exceeded. 

The  distributed  architecture  of  the  instrumentation  combined 
with  the  available  technology  makes  it  possible  to  not  only  meet  all  of 
the  identified  functional  requirements,  but  in  most  cases  to  exceed  them. 

2-4.2. 1  Weapon  Simulation  and  Real-Time  Casualty  Assessment.  In  order 
to  meet  the  stringent  RTCA  requirements  of  the  TNFS3  scenarios,  the 
weapon  simulator  has  features  never  before  feasible.  All  of  the  engage¬ 
ment  data  necessary  for  accurate  RTCA  is  made  available  to  the  player 
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pack  by  the  weapon  simulator.  This  maintains  player  autonomy  and  allows 
the  test  director,  not  the  instrumentation  designer,  to  determine  the  way 
casualties  are  assessed.  The  problem  of  close-in  engagements  has  been 
solved  by  the  development  of  a  laser  sensitive  fiber-optic  panel.  Using 
these  panels  of  laser  detecting  cloth,  it  is  now  possible  to  make  any 
area  of  a  human  or  vehicle  sensitive  to  the  weapon  simulator.  Helmets, 
vests,  and  other  odd  shapes  are  now  easily  instrumented.  The  system  also 
selectively  detects  the  areas  of  the  body  illuminated  in  an  engagement 
making  it  possible  for  the  first  time  to  realistically  consider  wounds  as 
a  part  of  attrition  analysis.  The  simulator  is  very  flexible  and  can  be 
easily  adapted  to  incorporate  new  weapon  types  as  required.  It  currently 
handles  the  Ml 6  and  the  .357  Magnum  handgun.  It  is  scheduled  to  include 
the  M60  machine  gun  next  year.  To  handle  future  growth,  it  is  also 
adaptable  to  certain  kinds  of  indirect- fire  simulators. 

2-4. 2. 2  Position  Location  Requirements  Are  Met.  To  accommodate  the 
wide  range  in  position  location  accuracies  required  by  the  identified 
scenarios,  the  system  is  designed  to  use  any  one  of  several  methods.  The 
choice  depends  on  both  the  accuracy  requirements  and  availability. 

LORAN-C  can  be  used  if  the  test  is  being  conducted  in  an  area 
where  it  is  available  and  if  the  inherent  accuracy  of  LORAN-C  is  adequate 
for  the  particular  test. 

Transponder  multi lateration  is  used  when  exceptionally  high 
accuracies  are  required  or  when  the  test  must  be  conducted  in  an  area 
where  LORAN-C  is  unavailable.  This  system  employs  portable  collapsible 
towers  and  can  be  set  up  quickly  anywhere. 

The  TNFS3  instrumentation  is  designed  to  be  compatible  with 
GPS/NAVSTAR  for  future  applications  whenever  that  system  becomes  opera¬ 
tional  . 
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2-4.3 


Low  Cost  Is  Designed  In. 

Low  cost,  both  initial  and  recurring,  is  a  natural  feature  of 
the  chosen  instrumentation  architecture.  This  approach  was  unavailable 
to  designers  in  the  past  and  so  the  costs  of  owning  and  operating  past 
systems  were  very  high. 

2-4. 3.1  Acquisition  Costs  Reduced  Through  Commonality.  Acquisition 

costs  have  been  kept  low  by  using  a  modular  design  and  then  using  the 
same  instrumentation  modules  in  all  of  the  subsystems.  This  allows  the 
buyer  to  take  advantage  of  quantity  discounts  in  the  initial  procurement 
and  reduces  the  number  of  separate  items  that  must  be  Dought  and  stored 
as  spare  parts. 

2-4. 3. 2  Recurring  Costs  Reduced  Through  Simplicity.  Low  recurring 
costs  of  operation  are  a  natural  feature  of  the  total  system  architec¬ 
ture.  The  simplicity  of  modular  hardware  and  software  reduces  the  size 
of  the  staff  required  and,  therefore,  reduces  the  recurring  direct  labor 
costs.  The  simplified  logistics  results  in  reduced  maintenance  costs. 

2-5  SUMMARY. 

The  distributed  processing  architecture  is  the  key  to  the 
success  of  the  development  program.  It  is  this  approach  that  allows  the 
myriad  of  apparently  conflicting  requirements  to  be  simultaneously  satis¬ 
fied  by  a  single  instrumentation  system  that  is  not  only  very  flexible 
and  very  powerful,  but  at  the  same  time  is  inexpensive  to  own  and 
operate. 
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SECTION  3 

SYSTEM  FUNCTIONAL  ELEMENTS 


3-1  INTRODUCTION. 

The  complete  instrumentation  system  consists  of  a  set  of  modu¬ 
lar  subsystems  working  together  in  a  coordinated  manner  to  provide  the 
required  real-time  data  acquisition  and  weapon  simulation  function  estab¬ 
lished  by  the  program  scoping  phase. 

This  section  describes  the  basic  features  of  the  TNFS3  sub¬ 
systems  and  how  these  subsystems  interact  to  fulfill  the  requirements 
specified  in  the  scoping  phase.  The  player  pack  is  the  primary  element 
of  an  instrumentation  system  which  also  includes  a  master  station,  a 
repeater/transponder  network,  and  a  position  location  subsystem.  All 
subsystems  are  modular;  a  variety  of  combinations  may  be  implemented  to 
meet  specific  needs.  This  section  describes  the  potential  combinations 
which  are  available;  Appendix  A  describes  in  detail  the  functional  and 
circuit  operation  of  these  various  sybsystems. 

The  player  pack  subsystems  are  composed  of  the  following  ele¬ 
ments  whose  operational  capabilities  are  also  described  in  this  section: 

1.  Microcomputer 

2.  Weapons  effects  subsystem 

3.  RF  communications  subsystem 

4.  Data  logging  subsystem 

3-2  PLAYER  PACK  ARCHITECTURE. 

In  order  to  meet  the  stated  requirement  for  adaptability  and 
flexibility,  the  player  pack  was  designed  to  architecturally  resemble  a 
standard  commercial  minicomputer.  A  computational/control  element  (the 
microcomputer)  drives  a  standard  common  peripheral  bus.  All  of  the 
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is  shown  schematically  in  Figure  4.  The  weapons  effects,  RF  communica¬ 
tions,  position  location,  and  data  logging  subsystems  are  general  in 
nature  and  communicate  with  the  computer  via  the  standard  bus.  This 
"peripheral  device"  role  of  all  the  hardware  elements  assures  easy  recon¬ 
figuration  of  the  player  pack  as  player  roles  change. 


Figure  4.  Instrumentation  Subsystems 

Each  of  the  printed  circuit  board  modules  forms  a  unique  func¬ 
tional  element  within  the  player  pack.  These  elements  are  independent  in 
their  operation  from  any  other  element.  Any  module,  from  any  source,  for 
any  purpose,  which  observes  the  bus  protocol  can  be  incorporated  into  the 
player  pack  as  a  peripheral  device. 

The  player  pack  software  also  reflects  the  flexibility  require¬ 
ments  of  the  program  and  is  implemented  in  a  manner  which  complements  the 
modularity  of  the  player  pack  hardware.  This  software  consists  of  an 
operating  system  kernel  which  controls  allocation  of  computer  resources 
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(CPU  time,  memory,  access  to  peripheral  devices,  etc.)  in  a  consistent 
manner  based  on  the  operational  real-time  importance  of  the  currently 
active  processes.  Peripheral  device  drivers  are  software  modules  that 
"plug  in"  to  the  operating  system  kernel  in  the  same  way  that  the  peri¬ 
pheral  hardware  plugs  into  the  player  pack.  To  further  increase  flexi¬ 
bility  and  ease  of  use,  the  player-related  computational  processes  are 
also  plug  in  software  modules  called  "tasks."  The  division  into  tasks 
vastly  reduces  the  effort  involved  in  producing  unique  player  software. 

3-3  PLAYER  PACK  FUNCTIONAL  ELEMENTS. 

3-3.1  Player  Pack  Microcomputer. 

The  player  pack  microcomputer  is  the  key  element  of  the  instru¬ 
mentation  system  (Figure  5).  It  provides  the  player  with  the  computing 
power  necessary  for  the  distributed  architecture  of  the  system.  Its 


Figure  5.  TNFS3  Microcomputer 
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function  is  to  process,  in  real  time,  all  of  the  player  activity  data 
supplied  by  the  peripheral  modules  and  subsystems.  It  is  the  replacement 
for  the  central  computer  of  the  older  centralized  instrumentation 
systems,  performing  RTCA  and  position  location  calculations  for  a  single 
player.  The  microcomputer  has  been  designed  to  assure  that  it  can  meet 
all  of  the  current  requirements  of  TNFS3,  and,  wherever  an  option  exists, 
features  have  been  implemented  in  the  way  that  reduces  the  initial  load¬ 
ing  on  the  system  and  provides  the  greatest  growth  potential. 

To  assure  meeting  the  requirements  of  flexibility  and  future 
growth  stated  in  Section  2-3.1,  the  microcomputer  has  been  designed  as  a 
general  purpose,  high  speed,  very  powerful  computing  element.  As  with 
any  computer,  the  software  provides  the  final  operational  function, 
whereas  the  microcomputer  itself  provides  the  capabilities  necessary  to 
implement  the  programmed  functions. 

3-3.  1.1  The  Central  Processing  Unit.  A  16-bit  microprocessor  manufac¬ 
tured  by  Texas  Instruments  was  selected  for  the  central  processing  unit 
(CPU)  in  order  to  meet  both  the  computing  capability  requirement  and  the 
instrumentation  development  cost  requirement.  The  following  were  key 
decision  factors  in  that  choice: 

1.  The  microprocessor  is  fully  supported  by  a  development  system 
which  includes  emulators  and  peripheral  devices. 

2.  The  instruction  set  and  interrupt  structure  is  optimized  to 
support  real-time  processing. 

3.  An  efficient  software  development  system  allows  software  to  be 
flexible  and  adaptable. 

4.  The  microprocessor  power  requirements  are  reasonably  low;  it 
operates  at  4  MHz. 

3-3. 1.2  Memory.  The  microcomputer  memory  is  designed  to  be  flexible 
and  expandable  for  future  growth.  Initial  loading  on  the  system  is 
reduced  by  selecting  random  access  memory  (RAM)  components  which  operate 


at  high  speed,  with  low  power  consumption.  These  memory  devices  execute 
software  which  is  loaded  from  the  EPROM  board  or  provide  temporary  data 
storage  during  field  tests. 

3-3. 1.3  Interrupts.  High  speed  prioritized  response  to  player  activity 
is  obtained  by  the  use  of  "interrupts"  for  data  acquisition.  Each  peri¬ 
pheral  device  in  the  player  pack  issues  a  signal  to  the  CPU  when  it  has 
data  ready  for  it.  These  signals  are  prioritized  so  that  the  data  of 
most  importance  to  the  test  has  the  highest  priority  signal.  When  any  of 
these  signals  is  activated,  the  CPU  stops  whatever  it  is  doing  and 
attends  to  the  peripheral  device  (the  CPU  gets  interrupted).  The  CPU 
always  services  the  interrupt  of  highest  priority  first. 

3-3. 1.4  System  Clock.  In  order  to  maintain  timing  synchronization 
between  the  independent  players,  each  is  equipped  with  a  real-time  clock. 
The  clock,  initialized  when  the  player  receives  his  ID  code,  maintains  an 
accuracy  of  better  than  1  second  per  day.  The  resolution  of  the  clock  is 
10  milliseconds,  and  all  player  activity  data  is  time  tagged  to  the 
nearest  10-millisecond  interval  as  it  is  acquired. 

3-3. 1.5  Direct  Memory  Access.  Direct  memory  access  (DMA)  is  provided 
to  implement  high  speed  data  transfers.  This  technique  allows  data  to  be 
transferred  at  rates  up  to  1,000,000  bytes  per  second  with  no  CPU  inter¬ 
vention.  Removing  the  high  speed  transfer  load  from  the  CPU  allows  it 
more  available  time  for  computational  tasks,  thereby  increasing  its 
growth  potential.  The  devices  presently  slated  to  use  DMA  are  the 
weapons  effects  subsystem,  the  RF  communication  subsystem,  and  the  data 
logger. 

3-3. 1.6  Floating-Point  Hardware.  To  guarantee  adequate  computational 
capability  and  responsiveness  to  computationally  driven  processes  such  as 
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RTCA,  the  microcomputer  is  equipped  with  floating-point  hardware.  Mathe¬ 
matical  operations  such  as  trigonometric  functions,  exponential  func¬ 
tions,  logarithms,  and  others  are  provided  by  this  on-board  peripheral 
device.  Since  it  operates  as  a  peripheral,  it  performs  these  functions 
in  parallel  with  the  CPU.  This  increases  the  total  throughput  of  the 
system  by  allowing  both  the  normal  CPU  processes  and  mathematically 
intensive  processes  to  proceeed  simultaneously. 

3-3. 1.7  Terminal  Interface.  To  provide  a  convenient  means  of  unloading 
data  at  the  end  of  each  test,  an  industry  standard  RS-232-C  interface  is 
included  on  the  microcomputer  board  as  an  on-board  peripheral  device. 
Because  this  is  a  general  purpose  standard  interface,  it  can  be  used  for 
a  variety  of  purposes  as  the  need  arises.  It  provides  the  interface  to 
the  key  entry  display  unit  (KENDU)  when  the  player  pack  is  used  to 
instrument  an  umpire  and  can  be  used  for  communication  with  a  wide  selec¬ 
tion  of  other  standard  terminal  devices  such  as  teletypes,  line  printers, 
etc.  as  required. 

3-3. 1.8  Summary.  The  microcomputer  board  has  been  designed  to  have  the 
equivalent  computational  capability  of  a  small  minicomputer.  It  is  a 
flexible,  expandable,  adaptable,  low  power,  general  purpose  computer  with 
a  great  deal  of  growth  potential.  The  architecture  is  optimized  for  the 
stringent  TNFS3  processing  environment.  The  technology  developments  of 
the  late  1970' s  have  made  this  development  possible  at  very  low  cost. 
The  entire  microcomputer  costs  only  $1,600,  a  small  fraction  of  the  cost 
of  an  equivalent  minicomputer.  Design  details  on  the  microcomputer  can 
be  found  in  Appendix  A,  Section  A-l. 

3-3.2  Weapons  Effects  Subsystem. 

The  need  for  a  weapons  effects  subsystem  for  TNFS3  stems  from 
the  real-time  casualty  assessment  (RTCA)  requirement  established  in  the 
scoping  phase  of  the  program  (Section  2- 4.2.1).  This  subsystem  provides 
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all  the  necessary  hardware  for  simulating  many  different  types  of  direct 
fire  weapons.  The  weapons  effects  subsystem  performance  requirements 
imposed  on  the  TNFS3  instrumentation  are  more  stringent  than  any  previous 
requirements,  and  several  key  developments  have  been  necessary  to  meet 
these  requirements.  Most  notable  of  these  is  the  development  of  the 
laser-sensitive  fiber-optic  panel  which  solved  the  close-in  engagement 
problem. 

The  weapons  effects  subsystem  basically  does  three  things:  (1) 
it  activates  the  weapon  simulator  when  the  player  pulls  the  trigger;  (2) 
it  provides  for  detection  of  the  simulator  signal  at  the  target  player; 
(3)  it  makes  the  engagement  data  available  to  the  player  pack  microcompu¬ 
ter  for  casualty  assessment  processing.  All  of  these  are  done  in  a 
manner  that  provides  a  sense  of  realism  to  the  players  and  minimizes 
negative  training  effects. 

Because  each  player  pack  operates  autonomously,  all  the  infor¬ 
mation  relevant  to  RTCA  must  be  made  available  to  the  target's  player 
pack.  Since  there  is  no  central  computer  to  supply  this  data,  everthing 
must  be  done  by  the  weapons  effects  subsystem.  The  necessary  information 
is  also  described  in  Appendix  A  and  includes: 

1 .  Attacker  ID 

2.  Weapon  type 

3.  Attacker  posture  (upright/prone) 

4.  Firing  mode  (auto/single  shot) 

5.  Attacker  position  coordinates  (for  slant  range) 

6.  Attacker  marksmanship 

3-3. 2.1  Weapon  Firing  Simulation.  To  simulate  firing  events,  an  eye- 
safe  laser  is  mounted  on  each  weapon.  The  laser  beam  is  used  to  simulate 
the  projectile.  Using  lasers  is  particularly  effective  since  the  diver¬ 
gence  of  the  beam  can  be  adjusted  to  closely  emulate  the  ballistic  spread 
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pattern  of  different  types  of  weapons.  To  provide  the  necessary  realism, 
the  laser  is  activated  by  the  muzzle  flash  produced  by  firing  a  blank 
round  (M-16  configuration  is  shown  in  Figure  6).  This  technique  requires 
that  the  player  not  only  carry  blank  ammunition  but  also  reload  the 
weapon  as  would  normally  be  required  in  combat. 

The  laser  beam  itself  is  used  to  transmit  the  attacker- related 
data  needed  for  real  time  casualty  assessment  (RTCA)  in  the  target's 
player  pack.  Pulse-position  modulation  is  used  to  impress  72  bits  of 
data  on  the  beam.  Therefore,  when  a  pairing  is  detected,  the  data  needed 
are  automatically  present. 

3-3. 2. 2  Weapon  Simulator  Detection.  To  detect  the  laser  beam  from  the 
weapon  simulator,  the  target  player  must  be  instrumented  with  detection 
devices  which  are  sensitive  to  the  laser  beam.  These  detectors,  located 
on  cloth  panels  incorporated  into  a  harness  worn  by  the  player,  cover 
four  critical  parts  of  the  body:  1)  head,  2)  front  upper  torso,  3)  front 
lower  torso,  and  4)  rear  torso.  When  the  laser  beam  from  a  weapon  simu¬ 
lator  illuminates  a  target  player,  these  sensors  detect  the  presence  of 
the  beam,  and  the  weapons  effects  electronics  (see  Appendix  A,  Section 
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A-5)  decodes  the  information  content  of  the  modulated  beam.  Since  RTCA 
for  TNFS3  must  be  highly  accurate  and  must  include  wounds,  the  electron¬ 
ics  also  records  exactly  which  of  the  detectors  on  the  body  were  illumi¬ 
nated  and  the  target  player's  posture. 

3-3. 2. 3  Transfer  of  Engagement  Data  to  the  Player  Pack.  When  an  incom¬ 
ing  laser  message  has  been  properly  decoded,  the  information  is  trans¬ 
ferred  to  the  target's  player  pack  for  casualty  assessment  processing. 
This  is  accomplished  through  a  high  priority  data  channel  in  the  player 
pack.  Segmenting  the  acquisition  of  the  engagement  data  and  the  RTCA 
process  in  this  way  makes  the  weapons  effects  subsystem  quite  versatile 
and  adaptable  to  many  weapon  types.  No  changes  to  the  subsystem  are 
required,  simply  a  change  in  the  RTCA  algorithm  in  the  microcomputer. 

3-3. 2.4  Combat  Realism.  Simulations  must  occur  with  the  highest  degree 
of  realism  possible.  To  enhance  the  realism  of  the  TNFS3  weapons  effects 
subsystem,  several  key  developments  have  been  accomplished. 

1.  Trigger-pull  is  detected  by  the  muzzle  flash  from  the  weapon. 
This  requires  the  player  to  carry  all  the  ammunition  he  intends 
to  use  and  to  reload  in  a  normal  fashion.  It  also  means  that 
players  who  run  out  of  ammunition  can  no  longer  impact  the 
scenario,  as  would  be  the  case  in  a  real  force-on-force  engage¬ 
ment. 

2.  There  is  no  direct  connection  (wire)  between  the  player  and  the 
weapon.  This  allows  the  player  to  use  any  weapon  available 
during  a  scenario. 

3.  If  the  player  is  determined  to  be  a  casualty,  the  player  pack 
microcomputer  disables  its  simulator.  This  assures  that  the 
player  can  no  longer  inflict  casualties  and  removes  him  from 
action. 

3-3. 2. 5  No  Negative  Training.  The  psychological  effect  of  cumbersome 
instrumentation  and  the  time  required  for  the  player  to  adjust  to  idio¬ 
syncrasies  of  the  equipment  is  referred  to  as  negative  training.  The 


weapons  effects  subsystem  has  been  designed  to  minimize  this  effect.  The 
weapons  used  are  real,  not  toys  or  replicas.  Therefore,  they  retain  the 
feel  and  balance  of  the  actual  weapon.  Furthermore,  the  player  is  never 
required  to  perform  any  activity  solely  related  to  operation  of  the 
simulator.  He  only  does  those  things  he  would  do  in  an  actual  combat 
situation. 

3-3. 2. 6  Sensor  Development.  Although  every  portion  of  the  weapons 
effects  subsystem  has  been  designed  to  enhance  realism,  minimize  negative 
training,  and  provide  "human"  engineering  aspects  to  the  system,  the 
single  most  important  development  has  been  the  area  sensor.  Previously 
used  sensors  presented  simulation  deficiencies  which  are  now  overcome  by 
the  use  of  the  area  sensor.  In  the  past,  the  laser  detectors  used  were 
discrete  photosensitive  elements  placed  in  strategic  locations  on  the 
body.  As  long  as  the  separation  between  the  attacker  and  the  target  was 
great  enough,  the  natural  laser  beam  expansion  would  guarantee  that  at 
least  one  of  these  discrete  detectors  would  be  illuminated.  However,  if 
the  engagement  were  "close-in,"  it  was  highly  likely  that  the  small  laser 
beam  would  entirely  miss  all  the  sensors,  illuminating  a  small  spot  in 
between  the  sensors.  Thus,  it  was  likely  that  a  player  shot  at  point- 
blank  range  would  "survive."  The  cost  in  both  dollars  and  weight  of 
using  a  dense  pattern  of  sensors  to  eliminate  the  "blind  spots"  is  prohi¬ 
bitive.  To  solve  this  problem  the  area  sensor  was  developed. 

The  area  sensor  is  fabricated  on  cloth  panels  using  fiber 
optics  for  light  coupling;  these  are  lightweight,  rugged,  inexpensive, 
and  flexible  enough  to  conform  to  odd  shapes.  The  panels  can  be  used  to 
form  a  "jump  suit"  for  humans,  making  the  entire  suit  a  detector.  The 
helmet  is  wrapped  with  an  area  sensor  to  instrument  the  head.  These 
panels  are  ideal  for  coverage  of  large  areas  such  as  vulnerable  parts  of 
vehicles. 

The  area  sensor  does  not  have  quite  the  sensitivity  of  the 
discrete  sensors.  It  is  effective  to  a  range  of  about  300  meters;  there¬ 
fore,  for  completeness  a  few  discretes  are  retained.  Figure  7  shows  the 
location  of  these  sensors  on  the  player's  vest.  Using  both  types  of 
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sensors,  the  weapon  effects  subsystem  promises  to  be  the  most  accurate, 
realistic,  and  flexible  weapon  simulation  scheme  developed  to  date. 

3-3. 2. 7  Weapon  Simulator  Development.  To  date,  two  weapon  simulators 
have  been  developed  for  the  weapons  effects  subsystem.  These  are  for  the 
M-16  and  .357  Magnum  handgun,  (see  Figure  8).  The  laser  beam  spread  is 
designed  to  simulate  the  ballistic  spread  of  each  type  of  weapon  instru¬ 
mented  and  therefore  is  flexible  enough  to  adapt  in  the  future  to  simula¬ 
tion  of  additional  weapons  such  as  the  M-60  machine  gun  and  the  .45 
cal iber  handgun. 

3-3.3  Position  Location  Subsystem. 

The  TNFS3  program  requires  instrumentation  that  can  accurately 
track  the  position  of  moving  players  during  the  test  scenarios.  The 
scoping  phase  detailed  the  importance  of  accurate  RTCA  which  in  turn 
depends  on  accurate  slant-range  determination.  Other  studies  (see  Sec¬ 
tion  2-3. 1.2)  have  detailed  the  direct  relationship  between  slant  range 
and  weapon  lethality.  The  most  straightforward  means  of  determining  the 
slant  range  is  to  compute  it  from  accurate  player  position  information. 

Engagement  model  verification  in  troop  deployment  or  perimeter 
defense  can  be  obtained  only  by  having  a  continuous  record  of  player 
location  during  the  test.  Because  the  accuracies  required  for  model 
validation  vary  a  great  deal,  depending  on  both  the  model  and  the  parti¬ 
cular  scenario,  the  TNFS3  instrumentation  has  been  designed  to  implement 
at  least  three  techniques  for  this  function.  This  approach  does  not  tie 
the  instrumentation  to  a  single  mode  of  operation  but  instead  allows  it 
to  adapt  to  external  constraints  as  required. 

One  of  the  possible  techniques  that  can  be  used  in  the  future 
is  GPS/NAVSTAR,  a  satellite-based  navigation  system  which  is  still  under 
development  and  slated  to  be  operational  in  1984.  The  other  two  systems 
are  fully  operational  and  available  now.  These  are  LORAN-C,  a  ship 
navigation  aid,  and  a  transponder-based  system  developed  especially  to 
meet  the  TNFS3  high  accuracy  requi rements. 
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3-3. 3.1  LQRAN-C  Characteristics.  The  constraints  that  are  placed  on 
position  location  accuracy  limit  the  potential  methods  of  calculating 
position  location.  One  low-cost  method  presently  available  in  most  parts 
of  the  world,  shown  in  Figure  9,  is  the  LQRAN-C  navigation  system.  In 
the  United  States  LORAN  is  maintained  and  operated  by  the  Coast  Guard  at 
the  frequencies  specified  in  Figure  9.  The  system  is  a  pulsed,  low- 
frequency  (LF),  hyperbolic  radio-navigation  system  that  derives  its 
accuracy  from  time  difference  measurements  of  the  pulsed  RF  signals  and 
the  inherent  stability  of  LF  propagation.  Wide  coverage  areas  are  made 
possible  by  the  low  propagation  losses  of  LF  groundwaves  and  the  resul¬ 
tant  long  baseline  lengths  (transmitter  station-to-station  separation). 
Hyperbolic  navigation  systems  operate  on  the  principle  that  the  differ¬ 
ence  in  time  of  arrival  of  signals  from  two  or  more  transmitter  stations, 
observed  at  a  point  in  the  coverage  area,  is  a  measure  of  the  distance 
from  the  point  of  observation  to  each  of  the  transmitter  stations. 

Ranges  of  800  to  1200  nautical  miles  (NM)  are  typical,  depend¬ 
ing  on  transmitter  power,  receiver  sensitivity,  and  losses  over  the 
signal  path.  Variations  in  propagation,  transmission  power  losses,  and 
velocity  introduce  errors  resulting  in  position  errors.  These  errors, 
and  those  introduced  by  the  receiver,  will  normally  yield  a  position 
location  accuracy  of  +200  feet  (60  meters)  at  500  NM  and  decrease  to  +500 
feet  (150  meters)  at  distances  of  1000  NM  from  the  transmitters. 

Results  from  the  L0RAN-C  RECEIVER  TESTING  AND  EVALUATION  FOR 
POSITION  LOCATION  (report  No.  BDM/M-005-80)  revealed  that  position  loca¬ 
tion  errors  were  reduced  significantly  when  the  receivers  were  used  in 
the  "repeatable"  mode.  Repeatable  mode  simply  means  that  the  receiver 
was  calibrated  with  known  time  differences  of  arrival  and  that  variations 
due  to  temperature,  humidity,  etc.  cancelled  out.  This  method,  using  raw 
L0RAN-C  data,  resulted  in  position  location  variations  of  less  than  +50 
meters.  Subjecting  the  raw  L0RAN-C  data  to  filtering  and  smoothing 
programs  reduced  position  location  variations  to  +20  meters.  Other,  more 
elaborate  methods,  such  as  strategically  placing  several  (four  or  five) 


40 


surveyi ng-type  LORAN  receivers  in  the  testing  area  and  feeding  back 
dynamic  grid  variations  to  player  receivers,  could  potentially  further 
reduce  position  location  errors. 

A  LORAN-C  system  may  be  easily  incorporated  into  the  TNFS3 
instrumentation.  A  lightweight  low-cost  LORAN  receiver  is  "piggy-backed'' 
on  the  player  pack  and  an  interface  module  properly  routes  the  receiver 
data  to  the  microcomputer.  Software  in  the  player  pack  can  easily  per¬ 
form  the  necessary  grid  conversions  and  smoothing  of  the  raw  LORAN  data. 

The  limitations  of  the  LORAN-C  system  must  be  considered  in 
light  of  the  scoping  requirements  mentioned  earlier.  LORAN-C  can  only  be 
used  where  the  LORAN  chain  is  established  and  operational.  This  includes 
the  costal  areas  of  the  United  States  and  limited  areas  elsewhere  in  the 
world  as  shown  in  Figure  9.  LORAN  is  only  moderately  accurate  (+20 
meters).  This  is  suitable  for  many  types  of  convoy  or  large-scale  dis¬ 
persal  tests  but  is  not  acceptable  in  the  small  close-in  engagement 
scenarios  identified  in  the  scoping  phase  of  the  TNFS3  program. 

3-3. 3. 2  Transponder-Based  Position  Location.  To  solve  several  of  the 
problems  which  are  inherent  in  LORAN-C  systems,  a  transponder  position 
location  (TPL)  subsystem  was  developed  by  BDM.  The  TPL  system  is  easily 
transportable  to  anywhere  in  the  world,  requires  only  a  short  setup  time, 
and  provides  the  high  accuracy  position  location  capability  required  by 
many  of  the  TNFS3  issues. 

The  TPL  system  operates  much  like  TACAN  aircraft  navigation 
system.  Using  a  low  power  radio  transceiver,  each  player  pack  can  mea¬ 
sure  the  round-trip  signal  flight  time  to  each  element  of  a  grid  of 
preset  transponder  towers.  The  signal  flight  time  is  proportional  to  the 
distance  between  the  player  pack  and  the  tower.  Combining  these  separate 
range  measurements  in  a  multilateration  calculation  yields  the  player 
position  relative  to  the  transponder  network. 

The  TPL  system  uses  the  same  radio  units  as  the  RF  communication 
system.  A  single  module  is  added  to  the  player  pack  to  provide  the 
additional  range  measuring  capability.  Since  measuring  the  flight  time 
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of  a  radio  signal  is  equivalent  to  electronically  measuring  the  velocity 
of  light,  very  high  speed  circuitry  is  used. 

Test  results  to  data  indicated  that  the  position  location  error  will 
be  less  than  +  3  meters  with  this  system. 

3-3. 3. 2.1  Direct  Ranging.  An  additional  feature  of  the  TPL  system 
not  available  with  any  of  the  other  options  is  direct  ranging.  This 
feature  is  available  with  no  additional  hardware  and  allows  the  direct 
measurement  of  the  si  ant- range  between  two  players.  This  capability  is 
very  important  for  engagements  occurring  inside  metal  enclosures,  such  as 
aircraft  hangars,  which  block  the  external  radio  signals.  Preliminary 
test  results  indicate  an  accuracy  of  +3  meters  can  be  expected. 

3-3.4  The  RF  Communications  Subsystem. 

The  RF  communications  subsystem  is  an  optional  feature  of  the 
TNFS3  instrumentation  system.  In  areas  where  absolute  secutrity  is  not  a 
requirement,  it  can  be  used  to  enhance  the  operational  features  of  the 
system.  Its  basic  function  is  to  provide  a  bidirectional  data  link 
between  the  players  and  the  master  station.  This  subsystem  is  a  very 
flexible,  software-controlled  use  of  the  repeater/transponder  network 
hardware.  In  its  basic  configuration,  shown  in  Figure  10,  it  provides  a 
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Figure  10.  RF  conmunications  network. 


medium  by  which  the  test  director  can  control  and  monitor  the  progress  of 
the  test  scenario.  The  more  exotic  possibl i 1 ities  include  real-time 
player  software  changes  and  raw  data  streaming.  It  can  be  used  during 
player  initialization  to  reduce  the  level  of  orchestration  required  to 
begin  a  test. 

Even  where  security  is  an  issue,  the  RF  communications  sub¬ 
system  can  be  used  to  acquire  player  status  and  position  for  display 
purposes  since  no  lethality  or  activity  data  is  actually  transmitted. 

3-3. 4.1  Communication  Protocol.  All  communications  are  initiated  by 
the  master  station.  The  master  station  sends  a  message  which  commands  a 
specific  player  or  a  group  of  players  to  perform  some  specified  activity. 
Each  player  in  the  test  is  assigned  a  unique  player  10  number.  Whenever 
the  master  station  needs  to  communicate  with  a  single  player,  it  does  so 
by  addressing  the  message  to  the  player  ID.  In  addition,  there  is  a 
universal  ID  to  which  all  player  packs  respond.  The  universal  ID  is  used 
for  global  messages  such  as:  start  test,  stop  test,  initialize  time  of 
day,  etc.  If  the  master  station  needs  data  from  a  particular  player 
pack,  it  sends  a  command  to  that  player  requesting  the  data.  The 
sequence  of  events  is: 

1.  Master  station  requests  status  from  player  X. 

2.  Player  X  identifies  that  this  message  is  addressed  to  him. 

3.  P layer  X  transmits  his  status. 

4.  Master  station  receives  player  X's  message. 

5.  Master  station  transmits  to  player  X  either  a  "data  received" 
or  a  "data  no  good--retransmit"  message. 

This  "handshaking"  protocol  accomplishes  two  major  procedural 
objectives:  First,  the  master  station  is  in  complete  control  of  all 
radio  traffic.  The  player  packs  simply  respond  to  commands,  they  do  not 
initiate  any  communications.  This  assures  that  the  communication  channel 
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does  not  get  garbled  by  asynchronous  transmissions.  Secondly,  the  hand¬ 
shake  assures  that  data  are  properly  received  at  the  master  station. 
This  eliminates  the  problem  of  unknown  radio  failures  or  storage  of 
meaningless  data  in  the  test  data  base.  The  problem  is  solved  at  its 
source  rather  than  after  the  test  is  over,  when  it  is  too  late  to  do 
anything  about  it. 

3-3. 4. 2  Control  Messages.  Universal  control  messages  are  used  to 
simultaneously  coordinate  the  activities  of  all  the  players  in  the  test. 
These  messages  are  addressed  to  the  universal  "all  players"  ID  and 
require  no  radio  response  from  the  player  pack.  Examples  of  control 
messages  are: 

1 .  Start  test 

2.  Stop  test 

3.  Change  time  (synchronize  all  player  packs) 

4.  Indirect  fire  (future  expansion  option) 

3-3. 4. 3  Command  Messages.  Command  messages  can  be  addressed  to  all 
players,  a  selected  group  of  players,  or  an  individual  player.  Commands 
generally  result  in  a  response  by  the  affected  player.  There  are  many 
possible  commands  but  three  are  of  particular  importance: 

If  the  transponder  position  location  option  is  used,  there  is  a 
group  command  to  begin  a  transponder  cycle.  This  message  causes  the 
repeater/transponder  network  to  switch  to  the  transponder  mode  of  opera¬ 
tion,  as  described  in  Section  3-3.3,  and  the  addressed  group  of  player 
packs  begins  acquiring  position  data. 

The  second  command  is  addressed  to  a  single  player  and  requests 
a  status  update.  The  player  pack  responds  by  transmitting  his  current 
position,  number  of  rounds  fired,  whether  he  is  still  alive,  and  other 
generic  information  useful  for  real-time  display  purposes.  Included  in 
the  status  message  is  information  about  the  operational  state  of  the 
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player  pack  hardware.  This  facilitates  early  identification  of  possible 
instrumentation  failures  and  aids  in  the  maintenance  operation. 

The  third  important  command  is  similar  to  the  status  message 
request  but  is  used  only  during  very  long  tests  where  security  is  not  a 
problem.  This  command  requests  the  player  to  transmit  his  raw  engagement 
data  to  the  master  station.  This  can  be  used  to  unload  players  during 
regrouping  to  save  time  or,  during  long  tests,  to  free  space  on  the 
player  pack's  internal  data  logger. 

3-3.5  Data  Logging  Subsystem. 

Security  requirements  when  testing  in  Europe  mandate  that  no 
telemetry  of  raw  test  data  should  take  place.  To  satisfy  this  requiremnt 
a  data  logging  subsystem  is  included  in  the  player  pack  to  retain  the 
test  data.  Shown  in  Figure  11,  it  is  implemented  using  the  latest  state- 
of-the-art  memory  device  --  a  magnetic  bubble  memory.  The  bubble  memory 
device  is  nonvolatile  so  its  contents  are  retained  even  if  power  is 
removed.  During  a  test  the  microcomputer  transfers  all  of  the  player 
activity  data  to  the  data  logger  where  there  are  kept  until  the  test  is 
over.  After  the  test  the  data  are  transferred  to  the  master  station  for 
validation  and  quick-look  analysis. 

In  addition  to  test  data,  the  status  of  the  player  pack  is 
continously  stored  in  the  data  logger  so  that  if  a  power  failure  occurs, 
the  state  of  the  player  pack  can  be  analyzed.  Also,  if  the  player  pack 
is  power  cycled  during  deployment,  to  conserve  battery  life,  it  remembers 
its  previous  state  when  it  is  repowered. 

The  data  logging  subsystem  also  stores  the  player  pack  operat¬ 
ing  software.  Using  the  bubble  memory  device  for  mass  storage  facili¬ 
tates  changes  and  updates  to  the  player  pack  software.  Whenever  software 
changes  are  needed,  a  new  version  of  the  software  is  downloaded  to  the 
player  pack  from  the  developement  system  through  any  of  the  available 
interfaces  or  by  simply  replacing  the  data  logger  module  in  exactly  the 
same  way  as  replacing  a  disk  cartridge  on  a  minicomputer. 


The  magnetic  bubble  memory  has  storage  capacity  of  1,000,000 
bits  of  data,  enough  for  a  normal  10-hour  test. 

3-3.6  Software  Storage  Subsystem. 

The  repeater/transponder  controllers  are  implemented  using  a 
player  pack  microcomputer.  In  this  application  there  is  no  data  storage 
requirement  but  there  is  a  software  storage  requirement.  To  reduce 
costs,  a  "plug  in"  compatible  software  storage  module  was  developed  using 
relatively  inexpensive  EPROMs  to  replace  the  magnetic  bubble  memory. 
This  module,  shown  in  Figure  12,  is  power  cycled  when  not  in  use  to 
conserve  batteries. 

3-4  MASTER  STATION. 

A  primary  objective  of  the  TNFS3  Instrumentation  Program  is  to 
provide  complete,  autonomus  operation  anywhere  in  the  world.  This  re¬ 
quirement  suggests  the  need  for  a  mobile,  self-contained  support  facility 
capable  of  monitoring  or  controlling  any  test  scenario. 

The  master  station  has  three  secondary/optional  uses:  it 
facilitates  on-site  O&M  operations,  it  may  be  used  for  command  and  con¬ 
trol  of  RF  communications,  and  it  may  be  used  to  produce  a  real-time 
display  of  player  activity. 

The  master  station  will  be  housed  in  an  air  transportable 
semi-trailer  outfitted  with  ride  suspension  and  self-contained  heating, 
cooling,  and  humidifying  systems.  Its  interior  will  be  split  into  two 
sections,  isolating  the  maintenance  area  from  the  computer.  Power  will 
be  supplied  from  either  a  commercial  power  grid  or  a  portable  generator. 

The  computer  area  is  being  designed  around  a  Texas  Instruments 
minicomputer  capable  of  handling  communications  protocol,  able  to  store 
data  unloaded  from  the  player  packs,  and  capable  of  performing  the  neces¬ 
sary  data  validation  and  quick-look  functions.  As  shown  in  Figure  13, 
the  master  station  controller  consists  of  two  processors,  one  acting  as  a 
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gure  12.  EPROM  board. 
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concentrator  for  the  RF  communication  system.  It  will  handle  all  RF 
system  related  processing  and  provide  data  in  the  burst  mode  to  the  main 
controller  for  recording  and  display.  The  hardware  for  the  controller 
and  concentrator  will  be  identical,  thus  significantly  reducing  the  spare 
parts  logistics. 

The  software  for  the  main  master  station  controller  will  run 
under  TI's  commercial  operating  system  (DX10).  This  will  significantly 
simplify  the  software  generation  task  and  reduce  the  time  and  risk.  All 
software  for  the  concentrator  remains  to  be  developed,  and  is  scheduled 
for  FY81 . 

9 

Tne  data  validation  feature  will  be  activated  immediately  after 
the  test,  allowing  the  test  director  to  quickly  make  decisions  regarding 
the  outcome  --  was  the  trail  valid  or  should  it  be  re-run.  The  ability 
to  validate  the  test  data  prior  to  player  recall  can  save  the  expense  of 
redeploying  all  the  players.  It  can  also  increase  the  number  of  trails 
per  day  since  the  director  can  immediately  move  to  the  next  issue  if 
valid  data  have  been  collected.  This  will  decrease  the  total  testing 
time  and  the  associated  cost. 

The  maintenance  area  of  the  master  station  will  have  work 
benches,  test  equipment,  spare  parts,  and  a  computer  terminal  to  assist 
the  small  staff  in  repairing  damaged  player  packs.  The  planned  layout  of 
the  master  station  is  shown  in  Figure  14. 

To  complete  the  mobile  test  facility,  one  or  two  additional 
trailers  will  be  required.  They  will  be  used  to  store  and  ship  player 
equipment  and  will  be  organized  so  that  a  minimum  of  setup  time  is  re¬ 
quired  to  prepare  the  players. 

To  accomodate  very  small  tests  (5  to  10  players  maximum)  and  to 
facilitate  instrumentation  tests  prior  to  a  master  station  being  avail¬ 
able,  a  lightweight  substitute  for  the  master  station  has  been  developed. 
Called  a  Player  Initializer,  it  is  a  player  pack  with  extended  capabil¬ 
ities.  Equipped  with  a  hand  held  key  entry  display  device  or  data  termi¬ 
nal,  it  can  be  used  to  perform  a  subset  of  the  master  station  functions. 
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It  can  initialize  players,  control  transponder  activity,  monitor  player 
activity,  and  unload  the  player  packs  posttest.  It  cannot  perform  quick- 
look  validation,  generate  displays,  or  handle  the  more  detailed  uses  of 
the  RF  communication  features.  Its  use  as  a  test  controller  is  tied  to 
the  nearby  availability  of  a  master  station  for  support. 

3-5  REPEATER/TRANSPONDER  NETWORK. 

The  repeater/transponder  network  provides  the  hardware  neces¬ 
sary  to  implement  both  the  RF  communication  subsystem  and  the  transponder 
position  location  subsystem.  These  systems  are  optional,  so  the  network 
is  required  only  if  either  of  these  features  is  desired. 

Several  elements  from  the  scoping  phase  of  the  program  are 
simultaneously  addressed  in  the  design  of  the  network:  In  order  to 
perform  accurate  transponder  ranging  for  position  location,  it  is  neces¬ 
sary  that  the  radio  frequency  be  kept  quite  high  so  that  the  signals 
propagate  in  straight  lines.  This  sets  the  frequency  at  or  above  1  GHz. 
However,  the  TNFS3  tests  will  be  conducted  in  "hilly  rolling  terrain." 
Therefore,  a  series  of  "repeaters"  is  required  to  propagate  the  "line-of- 
sight"  high  frequency  signal  across  this  terrain  and  around  metal  build¬ 
ings  which  the  signal  cannot  penetrate.  To  meet  the  mobility  require¬ 
ments,  these  repeaters  are  lightweight,  portable,  quickly  erected,  and 
easily  maintained.  The  radio  unit  on  the  player  pack  is  small,  light¬ 
weight,  and  low  power  to  conserve  batteries.  The  system  must  operate  in 
heavy  foliage,  so  the  low  power  radio  units  must  be  compensated  by  the 
design  of  the  repeaters  in  order  to  have  adequate  signal  strength  to 
punch  through  the  foliage. 

3-5.1  Repeater/Transponder  Station  Hardware. 

The  repeater/transponder  stations  consist  of  three  elements:  a 
collapsable  tower,  a  1.35-GHz  radio  tranceiver,  and  a  controller  imple¬ 
mented  with  an  enhanced  player  pack.  Figure  15  shows  a  complete 
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repeater/transponder  station.  Initial  setup  procedures  require  two 
persons  to  transport  and  secure  the  antenna-tower.  Surveying  is  only 
required  if  the  transponder  position  location  option  is  to  be  used.  The 
lightweight  aluminum  towers  expand  from  their  collapsed  configuration 
into  a  lattice  structure  whose  maximum  height  is  30  feet  (9  meters)  and 
which  will  withstand  winds  of  up  to  80  mi/hr  (128  km/hr).  A  weatherproof 
antenna  is  mounted  atop  the  tower;  the  controller  and  battery  are  placed 
on  the  ground.  The  battery  is  a  high  capacity  rechargable  unit  suffi¬ 
cient  for  a  full  week  of  operation.  A  special  module  is  added  to  the 
player  pack  controller  to  monitor  temperature  and  voltage. 

3-5.2  Radio  Transceiver  Operation. 

The  same  radio  transceiver  is  used  on  the  players  and  on  the 
repeater/transponder  towers.  This  provides  additional  system  module 
commonality  and  helps  reduce  both  initial  and  recurring  costs.  The  radio 
unit,  shown  in  Figure  16,  weighs  approximately  2  pounds  (1  kg)  and  has  a 
peak  power  output  of  20  watts.  To  provide  the  additional  signal  strength 
for  reliable  communication  through  dense  foliage,  the  repeater/trans¬ 
ponder  stations  can  be  equipped  with  optional  output  amplifiers  and  high 
sensitivity  receiver  preamplifiers.  This  combination  allows  the  repeater 
to  both  detect  the  weaker  player  pack  transmission  and  to  transmit  a 
strong  enough  signal  for  the  player  pack  to  detect. 

The  radio  is  pulse  modulated  with  a  low  duty  cycle  so  that 
there  is  no  safety  problem.  The  combination  of  high  frequency,  low 
power,  and  pulse  modulation  yields  a  system  that  nether  interferes  with 
nor  is  easily  interf erred  with  by  others. 

3-5.3  Repeater  Mode  of  Operation. 

The  repeater  mode  of  operation  provides  the  signal  propagation 
necessary  for  communication  beyond  line  of  sight.  To  guarantee  proper 
operation,  tower  placement  must  be  chosen  so  that  no  matter  where  on  the 
field  a  player  may  go,  he  is  always  within  line  of  sight  of  at  least  one 
repeater/transponder  tower.  This  placement  allows  the  repeater  to  relay, 
or  echo,  messages  to  and  from  the  player  and  the  master  station. 
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3-5.4  Transponder  Mode  of  Operation. 

Whenever  the  TPL  subsystem  option  is  used,  three  additional 
requirements  are  placed  on  the  repeater/transponder  network: 

First,  the  repeater  controllers  and  player  packs  are  equipped 
with  a  TPL  controller  module  (see  Appendix  A,  Section  A-8).  No  other 
hardware  changes  are  required.  This  module  recognizes  the  special  "do 
position  location"  command  issued  by  the  master  station;  this  command 
causes  the  controller  to  switch  to  the  transponder  mode  of  operation. 
The  TPL  module  also  controls  the  timing  of  the  transponder  ranging  se¬ 
quence. 

Secondly,  the  towers  must  be  surveyed  into  position.  In  most 
cases  this  means  only  that,  once  erected,  the  tower  coordinates  must  be 
determined  by  surveying.  Only  rarely  must  the  towers  actually  be  erected 
in  precisely  predetermined  locations.  The  surveying  requirement  arises 
from  the  mathematics  of  the  position  multi lateration  algorithm.  In  order 
to  locate  the  player  on  the  field,  the  distances  between  the  player  and 
at  least  four  towers  of  known  position  must  be  available.  As  described 
in  Section  3-3.3,  the  TPL  subsystem  provides  only  the  ranges;  the  posi¬ 
tions  of  the  towers  must  be  known  beforehand.  The  positioning  accuracy 
of  the  towers  is  reflected  in  the  final  accuracy  of  the  mul ti 1 ateration 
results,  and  surveying  provides  the  best  accuracy.  However,  Section 
3-3.4. 1  describes  a  means  of  attaining  moderate  accuracy  without  actually 
surveying  all  of  the  towers. 

Finally,  the  network  coverage  must  be  more  dense  than  for  the 
repeater-only  mode  of  operation.  The  mul ti lateration  algorithm  requires 
range  data  from  at  least  four  transponders  in  order  to  locate  the  player 
in  three  dimensions.  This  means  that  instead  of  the  player  always  being 
within  line  of  sight  of  one  tower,  he  must  always  be  within  line  of  sight 
of  at  least  four.  The  accuracy  of  the  algorithm  is  improved  if  more  than 
four  ranges  are  provided.  In  practice,  this  configuration  is  not  diffi¬ 
cult  to  achieve  and  usually  requires  only  addition  of  a  few  towers. 

Additional  details  of  the  transponder  mode  of  operation  can  be 
found  in  Appendix  A,  Section  A-8. 
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3-5.4. 1  Tower  Self-Survey  Feature.  The  unique  feature  of  "self¬ 
survey"  is  a  method  of  installing  radio  towers  without  extensive  survey¬ 
ing.  Four  of  the  towers  must  be  surveyed  into  position  to  serve  as  a 
coordinate  system  reference  grid.  The  remaining  towers  are  emplaced 
wherever  it  is  convenient  and  where  they  will  provide  the  necessary 
coverage.  After  emplacement,  the  individual  towers  are  treated  as  if 
they  were  players  and  are  told  to  "do  PL".  The  towers  measure  the  ranges 
between  themselves  and  the  surveyed  towers  and  then  compute  their  own 
positions.  Although  this  method  of  determining  the  tower  coordinates  is 
not  as  accurate  as  surveying,  it  is  totally  acceptable  for  many  of  the 
scenarios  and  it  greatly  reduces  the  pretest  setup  time. 

3-6  UMPIRES. 

The  addition  of  umpires  to  the  TNFS3  instrumentation  system  contri¬ 
butes  to  the  flexibility  requirements,  mentioned  in  Section  2-4.1,  where¬ 
by  a  wide  range  of  scenarios  may  be  accomodated,  quickly  and  at  low  cost. 
Umpires  are  valuable  observers  during  a  test,  communicating  with  the 
master  station  or  acting  independently.  Each  umpire  will  carry  a  hand 
held  key  entry  device  and  a  player  pack,  so  that  specific  actions  of 
players  may  be  recorded.  The  umpire  may  trigger  indirect  fire  simulation 
casualties  resulting  from  it.  Other  possibilities  include  initializing 
player  packs  at  remote  locations,  testing  player  equipment  which  may 
become  inoperative,  or  aiding  the  master  station  in  controlling  the  test. 

All  of  the  above-mentioned  activities  are  simplified  through  the  use 
of  a  hand  held  key  entry  display  device.  The  touch-sensitive  keyboard 
will  be  coded  with  any  combination  of  numbers,  letters,  or  pictures  which 
can  improve  the  efficiency  of  the  umpire.  This  provides  a  choice  between 
single  key  messages  or  complete  messages  as  might  be  recorded  in  a  note¬ 
book.  Since  the  umpire  is  also  a  mediator,  this  person  may  reinitialize 
players  which  have  been  declared  dead  or  out  of  ammunition.  The  umpire 
also  carries  a  laser  weapon  which  may  wound  or  kill  selected  players  as 
might  be  necessary  in  indirect  fire  situations. 
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APPENDIX  A 

DETAILED  FUNCTIONAL  DESCRIPTION 

A- 1  MICROCOMPUTER-CENTRAL  PROCESSING  UNIT. 

A-1.1  Functional  Elements  of  the  Microcomputer. 

The  CPU  selected  is  the  TMS9900-40,  an  NMOS  device  manufactured  by 
Texas  Instruments.  It  operates  in  conjunction  with  three  other  devices,  a 
CMOS  oscillator,  a  programmable  systems  interface  (PSI),  and  a  four-phase 
clock  generator  which  operates  at  a  rate  of  4  MHz.  Memory  access,  to  a 
maximum  of  64K  bytes,  is  achieved  through  a  16-bit  data  bus  and  a  15-bit 
address  bus.  The  PSI  prioritizes  and  encodes  15  interrupt  inputs  into  the 
CPU.  As  an  interval  timer  it  is  programmed  to  generate  an  interrupt,  acting 
as  a  real-time  clock.  The  CPU  is  shown  in  Figure  A-l. 

System  memory  provides  storage  for  programs  and  data.  CMOS  com¬ 
ponents  (EPROM  and  RAM)  were  selected  for  their  low  power  consumption.  The 
EPROMs  operate  during  board  power-up  to  boot  the  system  program  stored  on 
the  EPROM  board.  The  contents  of  the  EPROM  board  are  transferred  into  RAM 
by  the  CPU.  When  this  process  is  complete,  the  CPU  turns  the  EPROM  board 
off  to  reduce  power  consumption.  The  RAM  devices  on  the  microcomputer  board 
represent  28K  bytes  of  memory,  with  an  additional  32K  bytes  potential  for 
off-board  expansion. 

The  module  select  logic  provides  an  efficient  method  of  selecting 
dedicated  circuit  board  slots  or  devices.  Its  decoding  scheme  minimizes 
circuit  components  when  selecting  DMA,  APU,  PSI  or  any  off-board  device. 
The  module  select  circuitry  decodes  the  10  most  significant  address  lines  to 
produce  16  unique  MODSEL  signals.  The  remaining  five  address  lines  provide 
32  addresses  within  each  MODSEL  field. 

The  direct  memory  access  (DMA)  controller  is  the  AMD9517.  Data 
acquisition  transfers  are  greatly  improved  when  this  component  acts  in  place 
of  the  CPU,  achieving  a  maximum  transfer  rate  of  1,000,000  bytes  per  second. 
This  is  possible  on  any  one  of  the  four  DMA  channels  available.  Anticipated 
users  of  DMA  included  the  weapons  effects,  RF  communications,  and  bubble 
memory  subsystems. 
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The  APU,  an  AMD9511 ,  is  a  dedicated  processor  which  operates  in 
parallel  with  the  CPU.  Arithmetic  calculations  in  fixed  or  floating  point 
notation  are  performed  on  trigonometric,  logarithmetic  and  exponential  func¬ 
tions.  This  NMOS  device  is  power  cycled  by  the  CPU  when  not  in  use.  During 
operation  it  consumes  1.2  watts. 

The  UART  is  a  CMOS  device,  the  RCA  1854,  dedicated  as  a  terminal 
interface  between  the  CPU  and  peripherals  over  an  RS-232-C  type  line.  Such 
devices  as  video  display  terminals,  line  printers,  and  the  key  entry  device 
communicate  with  the  player  pack  through  this  interface.  The  UART  is  pro¬ 
grammed  by  the  CPU,  selecting  between  five  and  eight  bits  per  byte  and  a 
parity  check  if  desired.  Seven  jumper  selectable  baud  rates,  300  to  19,200 
baud,  are  avai lable. 

A- 1.2  Power  Requirements. 

In  order  to  permit  battery  operation,  power  usage  for  the  micro¬ 
computer  was  minimized  through  the  careful  selection  of  low  power  components 
and  the  design  of  power  cycling  circuits.  CMOS  devices  are  utilized  wher¬ 
ever  possible;  low  power  Schottky  devices  are  a  desirable  substitute  when 
necessary.  This  procedure  was  valuable  in  producing  a  microcomputer  whose 
average  power  consumption  is  3.5  watts. 

A- 1 . 3  Board  Layout. 

The  microcomputer  board  size  was  selected  to  be  that  of  two  peri¬ 
pheral  boards,  assuring  maximum  efficiency  and  meeting  packaging  goals.  It 

TM 

is  fabricated  on  a  Multiwire  board  measuring  6.60  by  10.87  inches  (16.76 
by  27.61  cm).  The  Multiwire  method  of  fabrication  provides  maximum  circuit 
density  without  sacrificing  quality  or  durability.  The  board  interfaces  to 
a  motherboard  through  three  40-pin  connectors.  A  picture  of  this  board  and 
a  functional  block  diagram  is  shown  in  Figure  A-l. 

A- 1.4  Summary. 

The  general  purpose  of  the  microcomputer  is  to  function  as  a  nigh 
speed  computer  with  features  needed  for  the  TNFS3  program.  It  is  one  com¬ 
ponent  of  a  modular,  flexible,  expandable  system  which  is  both  durable  and 
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affordable.  The  software  it  contains  makes  it  "be"  a  player,  for  whoever 
and  whatever  is  desirable. 


A- 2  DATA  LOGGING  SUBSYSTEM. 

Security  requirements  when  testing  in  Europe  mandate  that  no 
telemetry  of  raw  test  data  should  take  place.  To  satisfy  this  requirement  a 
data  logging  subsystem  was  implemented  using  a  magnetic  bubble  memory.  The 
data  logging  subsystem  stores  all  player  test  data  in  the  player  pack  and 
thereby  eliminates  the  need  for  telemetry. 

For  the  repeater/transponder  stations,  where  test  data  are  not 
stored,  a  different  memory  subsystem  is  used  for  software  storage  alone. 
The  EPROM  module  is  much  less  costly  and  replaces  the  data  logging  subsystem 
in  the  repeater/transponder  stations. 

A-2.1  Functional  Description  (Bubble  Memory). 

To  provide  the  necessary  data  storage  capability,  data  density, 
high  reliability,  and  immunity  to  shock  and  vibration,  a  bubble  memory 
devi .  has  been  selected  for  the  TNFS3  player  pack  data  logger. 

The  bubble  memory  system,  shown  in  Figure  A-2,  consists  of  a 
one-megabit  storage  device  together  with  its  associated  control  electronics. 
It  interfaces  to  the  player  pack  microcomputer's  standard  peripheral  bus  in 
the  same  way  as  all  other  peripheral  devices.  If  additional  storage  capa¬ 
bility  is  needed,  several  data  logging  modules  can  be  plugged  into  the 
player  pack. 

The  data  logging  subsystem  utilizes  one  of  the  high-speed  DMA 
channels  for  data  transfers,  thereby  relieving  the  CPU  of  the  burden  of 
transferring  all  the  data. 

Operation  of  this  device  requires  a  great  deal  of  power.  There¬ 
fore,  power  is  turned  off  completely  when  the  micrcomputer  is  not  accessing 
the  device.  Additionally,  data  to  be  written  to  the  bubble  memory  are 
stored  in  RAM  until  enough  have  accumulated  to  allow  burst  transfer  of  a 
large  data  buffer.  This  also  helps  reduce  the  total  powe^  consumption. 
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The  bubble  memory  controller  has  built-in  capability  for  data 
error  detection  and  correction  in  addition  to  implementing  parity  for  error 
detection. 

A-2.1.1  Principle  of  Operation.-  The  principle  of  operation  is  quite 
simple:  the  CPU  programs  the  DMAC  to  transfer  the  data  stored  in  RAM  to  the 
bubble  memory,  it  then  turns  on  power  to  the  device  and  programs  the  con¬ 
troller  to  accept  the  data.  When  it  is  ready,  the  bubble  memory  controller 
signals  the  DMAC  to  begin.  The  DMAC  takes  control  of  the  peripheral  bus  and 
does  a  high  speed  transfer  of  the  data.  When  the  transfer  is  complete,  the 
bubble  memory  controller  signals  the  CPU  and  the  CPU  turns  off  power.  The 
direction  of  the  transfer  is  reversed  to  remove  data  from  the  bubble. 

A -2.2  Software  Storage  Module  (EPROM). 

The  EPROM  board,  shown  in  Figure  A-3,  was  developed  to  replace  the 
bubble  memory  module  when  data  logging  is  not  needed.  In  the  repeater/ 
transponder  application,  data  logging  is  not  needed  and  the  EPROM  module 
serves  as  low  cost  storage  for  the  operating  software.  Similar  to  the 
bubble  memory,  the  module  is  power  cycled  to  reduce  power  consumption. 

The  EPROM  module  has  a  storage  capacity  of  32K  bytes  of  software. 
In  the  repeater/transponder  application  the  module  also  supplies  the  micro¬ 
computer  with  a  unique  10  that  identifies  each  repeater/transponder  so  that 
it  can  be  independently  addressed  during  transponder  position  location 
cycles  as  described  in  Section  3-3.5. 

A- 2.2.1  Principle  of  Operation  (EPROM).  The  EPROM  module  is  software 
controlled  by  the  microcomputer  board.  Address  and  data  transfers  are 
initiated  by  the  CPU,  allowing  the  contents  of  the  EPROMS  to  be  loaded  into 
RAM.  Whenever  desired,  the  EPROMs  may  be  reprogrammed  by  exposing  the  EPROM 
chips  to  ultra-violet  light. 

Power  cycling  buffers  isolate  the  EPROM  data  bus  from  the  system 
data  bus  when  the  board  is  in  the  stand-by  mode.  This  mode  of  operation 
consumes  about  100  mW  compared  to  1 . 5  watts  when  ful ly  powered  up. 
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The  counters  sequence  through  the  local  addresses  of  the  module  so 
that  each  time  the  CPU  reads  a  byte  from  the  module  the  next  byte  is  present 
at  the  interface.  The  counters  can  be  accessed  by  the  microcomputer  and 
programmed  to  start  sequencing  at  any  address  and,  if  necessary,  read 
partial  contents  of  the  module.  Likewise,  the  unique  ID  code  used  in  the 
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Figure  A-3.  EPROM  board. 

repeater/  transponder  application  can  be  accessed  and  read.  Each  EPROM 
module  also  contains  another  10  code  which  is  used  to  distinguish  between 
EPROM  modules  and  bubble  memory  modules.  This  ID  code  can  also  be  used  to 
identify  different  versions  of  software  stored  in  the  module. 
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PLAYER  PACK  POWER  SOURCE. 


Since  the  player  pack  is  to  be  man  portable,  it  must  operate  from 
a  battery  source.  This  power  source  must  be  conditioned  by  the  appropriate 
regulator  circuit  to  supply  adequate  current  and  voltage  for  expected  player 
pack  operation.  It  was  designed  for  automatic  shutdown  should  the  battery 
drop  below  a  predetermined  minimum  where  regulation  becomes  impossible.  A 
warning  system  is  included  to  alert  the  player  of  such  a  failure,  with  a 
beeper,  so  that  a  defective  battery  can  be  immediately  replaced.  Also,  any 
player  data  still  in  RAM  locations  of  memory  must  be  transferred  to  the 
nonvolatile  bubble  memory  device  before  the  regulator  card  turns  off  the 
entire  player  pack.  This  procedure  eliminates  catastrophic  failures  and 
allows  graceful  failure  of  the  player  pack,  should  it  fail  unexpectedly. 

A-3.1  Functional  Description  of  the  Regulator  Card. 

The  regulator  card  is  a  plug-in  module,  shown  in  Figure  A-4,  that 
is  carried  in  every  player  pack.  Its  prime  function  is  to  supply  5  volts  to 
all  electronic  circuits  in  the  pack.  The  voltage  conversion  is  acceptable 
as  long  as  the  supply  battery  is  between  15  and  24  volts.  Conversion  is 
made  with  a  high  efficiency  (75  percent)  switching  circuit  to  maximize 
battery  life  and  time  between  charge  cycles.  Additionally,  the  regulator 
card  monitors  the  battery  voltage  to  provide  data-retention  security  if  a 
battery  pack  fails.  This  shutdown  also  occurs  in  the  case  of  a  microcom¬ 
puter  failure. 

To  extend  scenario  test  time,  a  power  saving  circuit  on  the 
regulator  card  allows  portions  of  the  player  pack  electronics  to  be  shut 
down  when  not  in  use.  This  feature  is  applicable  during  deployment  phases 
of  testing  when  the  data  logger  and  RF  communications  subsystems  are  not 
operating. 

A-4.  INTERFACE  MODULE. 

The  purpose  of  interface  modules  is  to  improve  the  flexibility  of 
the  player  pack  in  communicating  with  the  outside  world.  As  mentioned  in 
Section  2-2.1,  peripheral  devices  are  to  be  easily  reconfigured  and  still 
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provide  two-way  communications  with  the  player  pack.  Their  response  to  data 
transfers  adheres  to  specifications  in  Section  1-1.4,  whereby  the  "quick 
look"  feature  for  posttest  data  validation  is  successful. 

A-4.1  Functional  Description  of  the  Interface. 

A  general  purpose  interface  module  has  been  developed  to  allow  the 
microcomputer  to  communicate  with  external  devices.  The  Universal  Input/ 
Output  (I/O)  module,  shown  in  Figure  A-5,  is  a  software  activated  device 
that  facilitates  the  transfer  of  data.  Presently  the  module  is  an  add-on 
feature  for  test  equipment  or  cueing  devices.  It  interfaces  with  almost 
anything  (e.g.  ,  RS-232,  IEEE-488,  other  logic  devices,  and  data  busses).  As 
a  controller,  the  Universal  I/O  could  be  used  to  activate  or  monitor  flash/ 
bang/smoke  devices,  TV  cameras,  intrusion  detectors,  or  weather  stations. 

A-4.2  Operation  of  the  Universal  I/O. 

The  Universal  I/O  module  provides  16  input  lines  and  16  output 
lines.  The  microcomputer  may  address  each  input  or  output  line  as  an  inde¬ 
pendent  digital  signal  or  in  groups  of  up  to  16  lines.  Communication  is 
provided  through  the  communication  register  unit  bus. 

Each  output  will  interface  to  any  system  requiring  a  0  to  24- volt 
swing  with  almost  any  load  requiring  several  hundred  milliamps  of  current. 
The  outputs  are  capable  of  driving  inductive  loads  such  as  relays.  Input 
voltages  from  a  standard  24-volt  logic  level  system  are  acceptable,  with 
protection  from  input  transients  of  up  to  2  kilovolts  for  1  second. 

A-5.  WEAPONS  EFFECTS  SUBSYSTEM. 

The  weapons  effects  subsystem  consists  of  three  major  components: 
(1)  weapon-mounted  electronics,  (2)  laser  sensors,  and  (3)  communications 
interface  unit.  Information  is  bidirectionally  transmitted  from  the  weapons 
effects  interface  to  the  microcomputer. 

A-5. 1  Weapon-Mounted  Electronics. 

This  portion  of  the  weapons  effects  subsystem  includes  the  laser 
with  associated  circuits  and  the  interface  between  the  weapon  and  player. 
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Figure  A-5.  Universal  input/output  board. 


For  the  M-16,  the  laser  and  circuitry  is  housed  in  an  aluminum  casing  which 
mounts  on  top  of  the  rifle  barrel.  A  9-volt  alkaline  battery  to  power  these 
circuits  is  also  in  this  casing.  This  is  a  compact,  lightweight  (about  8 
ounces)  design  which  is  boresighted  to  the  weapon.  Figure  A-6  provides  a 
view  of  this  attachment. 

The  laser  beam  divergence  is  1.2  milliradians  and  exits  the  folded 
optics  window  with  a  diameter  of  approximately  3/4  inch  (19  mm).  Peak  power 
laser  output  is  approximately  2.5  watts  for  the  M-16.  With  current  sensor 
designs,  the  rifle  is  effectively  simulated  at  distances  exceeding  1  kilo¬ 
meter.  A  signal  cable  connects  the  laser  to  the  modified  handgrip.  This 
handgrip  contains  a  coil  of  wire  which  serves  as  one  side  of  an  air-core 
transformer.  The  transformer  forms  a  wireless  coupling  for  signals  between 
the  weapon  and  a  glove  (worn  by  the  player)  which  contains  the  other  trans¬ 
former  winding.  This  technique  eliminates  any  direct  hard  connection  between 
the  player  and  the  weapon,  allowing  the  player  to  interchange  weapons  at 
will.  The  glove  is  a  fingerless  design  (see  Figure  A-7)  which  can  be  worn 
either  under  or  on  top  of  regular  gloves.  This  interface  glove  is  designed 
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to  be  worn  with  the  coil  located  on  the  back  side  of  the  hand  in  order  to 
preserve  the  feel  of  the  weapon. 

A  .357  Magnum  handgun  (see  Figure  A-8)  has  been  configured  with 
electronics  but  is  presently  in  the  development  phase.  For  this  handgun, 
the  barrel  casing  is  replaced  with  a  laser  transmitter  casing.  The  beam 
spread  of  this  laser  is  approximately  4  milliradians.  This  simplifies  the 
optics  and  keeps  the  site  of  the  unit  as  unobtrusive  as  possible.  The  wider 
beam  spread  for  the  handgun  and  a  lower  power  laser  (approximately  2.0  watt 
peak)  makes  this  weapon  simulator  usable  to  about  100  meters  with  current 
sensor  designs.  As  with  the  M-16  implementation,  data  transfer  is  via 
inductive  coil  in  the  weapon  handgrip.  On  the  .357  Magnum,  however,  both 
the  circuit  for  the  laser  transmitter  and  the  battery  (a  6-volt  mercury 
cell)  are  housed  in  the  handgrip.  The  original  handgrip  is  detached  from 
the  weapon  by  removing  one  screw  and  replacing  it  with  the  electronics/ 
interface  kit  grip. 

A-5.2  Laser  Sensors. 

There  are  two  types  of  sensors  used  to  detect  the  laser  beam:  (1) 
discrete  sensors  and  (2)  area  sensors.  Each  has  different  characteristics 
and  the  combination  of  the  two  enhances  the  weapons  effects  subsystem 
performance. 


Figure  A-8.  .357  Magnum  handgun. 


A-5.2.1  Discrete  Sensor  Characteristics.  The  discrete  sensor  shown  in 
Figure  A-9  is  a  high  sensitivity  unit  capable  of  detecting  pairings  at 
distances  of  over  1  kilometer  (where  the  laser  beam  intensity  is  very  low 
because  of  spreading).  A  silicon  photodiode  is  used  as  the  detection 
device.  It  is  housed  with  a  signal  conditioner  circuit  in  a  small  aluminum 
box.  The  conditioner  circuit  amplifies  the  signal  from  the  photodiode, 
making  it  compatible  with  electronics  inside  the  player  pack.  The  design  of 
the  signal  conditioner  also  nulls  out  ambient  light  effects  on  the  photo¬ 
diode.  The  photodiode  is  mounted  against  a  window  in  the  box  with  an  EMI 
shield  between  it  and  the  glass  window.  The  main  deficiency  of  the  discrete 
type  sensor  is  that  it  is  susceptible  to  reflections  because  of  its  high 
sensitivity.  It  is  not  a  cost  effective  solution  to  instrumenting  large 
areas  of  the  target  because  of  its  relatively  small  window  area. 

A-5.2.2  Area  Sensor  Characteristics.  In  contrast  to  the  discrete  sensor, 
the  area  type  sensor,  shown  in  Figure  A-9,  has  relatively  low  sensitivity. 
Nonetheless,  it  is  usable  at  distances  of  over  300  meters  with  a  2.5-watt 
peak  power  laser  weapon  (M-16).  It  is  not  susceptible  to  reflections  of  the 
beam  to  any  significant  degree.  This  sensor  employs  the  same  silicon  photo¬ 
diode  and  signal  conditioner  as  the  discrete  sensor  type;  however,  the  light 
coupling  is  not  via  a  window  on  the  aluminum  box.  The  light  is  coupled  to 
the  photodiode  via  fiber  optic  strands  which  are  sewn  to  the  cloth  of  the 
players'  suit.  For  ruggedness,  the  fibers  are  jacketed  in  teflon  tubing 
prior  to  attachment  to  the  cloth.  A  reflective  material  is  used  behind  the 
fibers  to  enhance  light  scattering  effects  and  maximize  coupling  of  light 
energy  into  the  fibers.  An  outer  cloth  covering  the  fibers  serves  as  a 
protective  layer  and  allows  a  camouflauge  outer  appearance  to  be  maintained 
for  the  player.  The  ends  of  10  loops  are  terminated  in  a  connector  on  one 
end  of  the  signal  conditioner/photodiode  box,  and  the  photodiode  is  aligned 
with  the  fiber  ends  ror  maximum  light  transmission.  The  main  advantages  of 
the  area  type  sensor  are:  (1)  detection  of  close  engagements,  (2)  low 
susceptibility  to  reflections,  and  (3)  easy  coverage  of  large,  irregularly 
shaped  objects. 
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Figure  A-9.  Weapons  effects  sensors. 


A-5.2.3  Combined  Sensor  Arrays  for  the  Player.  Using  combinations  of  the 
two  types  of  laser  sensors,  the  player  "suit"  enables  detection  of  hits  on 
the  head,  upper  and  lower  front  torso,  and  rear  torso  of  the  player.  The 
head  coverage  is  via  an  area  sensor  attached  to  a  helmet,  shown  in  Figure 
A- 1 0 .  The  front  torso  coverage  combines  one  area  and  two  discrete  sensors 
for  the  upper  half  and  one  area  sensor  for  the  lower  half.  This  vest  or 
apron  is  fabricated  as  a  detachable  panel  and  is  worn  over  normal  clothing. 
The  back  torso  is  covered  by  one  area  and  two  discrete  sensors.  This  is 
also  a  detachable  panel  which  is  attached  to  the  back  of  the  player  pack. 
All  cables  to  the  sensor  panels  are  routed  through  a  single  connector  on  the 
interface  plate  (outer  cover)  of  the  player-pack  box.  Also  mounted  on  the 
shoulder  area  of  the  vest  is  a  sonalert  which  is  used  to  cue  the  player  when 
he  has  been  hit/wounded/killed.  The  electrical  connections  to  the  beeper 
are  routed  through  the  weapons  effects  connector. 


AREA  SENSOR 
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Figure  A- 1 0 .  Player  helmet  with  area  sensor. 
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A-5.3  Communication  Interface  Unit. 

In  order  to  determine  the  status  of  the  player  after  i 1 lumination, 
the  engagement  data  must  be  transferred  from  the  weapons  effects  subsystem 
to  the  player-pack  microcomputer.  This  is  accomplished  by  the  communica¬ 
tions  interface  unit  (CIU).  The  CIU  is  the  module  which  controls  all  com¬ 
munications  between  microcomputer  and  the  weapon/sensor/glove  subsystem.  As 
shown  in  Figure  A- 11,  the  CIU  contains  two  major  electronics  circuits.  The 
first  one  is  the  encoder.  Upon  detection  of  a  trigger  pull,  the  encoder 
formats  player  status  information  into  a  pulse-coded  message  which  modulates 
the  laser  beam.  Conversely,  the  decoder  circuit  of  the  CIU  receives  incoming 
data  (modulated  laser  light)  from  the  discrete  and  area  sensors  and  trans¬ 
forms  this  pulse  train  into  parallel  data  for  the  player  pack  microcomputer. 
The  CIU  also  contains  a  memory  area  to  buffer  incoming  and  outgoing  informa¬ 
tion.  This  allows  asynchronous  operation  of  the  encoder  and  decoder.  In 
other  words,  a  firing  player  can  be  hit  at  the  same  time  with  no  loss  of 
data.  The  CIU  also  contains  circuitry  to  operate  the  glove  side  of  the  coil 
interface  to  the  weapon.  Power  consumption  of  the  CIU  is  approximately  0.25 
watts. 

A-5.4  System  Dynamic  Operation. 

To  detail  the  operational  aspects  of  the  weapons  effects  sub¬ 
system,  it  is  convenient  to  divide  the  sequence  of  events  into  two  sections; 
(1)  a  firing  event  and  (2)  a  hit  event. 

A-5.4.1  Fire  Event.  A  fire  event  begins  when  the  player  pulls  the  trigger 
of  his  weapon.  The  fire  event  is  detected  by  the  weapon-mounted  electronics 
and,  in  the  case  of  the  M-16,  the  muzzle  flash  is  detected  (blank  round 
fired).  For  the  .357  Magnum,  the  impact  of  the  hammer  is  sensed.  Once  the 
trigger  pull  is  detected,  a  set  of  pulses  which  correspond  to  the  type  of 
weapon  fired  are  sent  to  the  coil  in  the  weapon  handgrip.  The  coupling  from 
» ne  handgrip  to  the  glove  enables  this  set  of  pulses  to  be  received  by  the 
. ; j  If  the  player  has  changed  weapon  types  since  last  firing,  the  micro- 
myuter  is  notified  of  this  and  a  player  status  buffer  is  updated  to 
»<;t  the  new  weapon  ID  number.  If  it  is  not  a  new  weapon  type,  the 
of  the  player  status  buffer  need  not  be  updated  and  the  message  is 
.  •,  •  .end  This  buffer  contains  the  following  information: 
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1 .  Attacker  ID 


2.  Weapon  Type 

3.  Attacker  posture  (upright/prone) 

4.  Firing  mode  (auto/single  shot) 

5.  Attacker  location  (x,y,z) 

6.  Attacker  marksmanship 

To  send  the  message,  the  encoder  circuit  reads  this  buffer  and 
formats  it  into  a  pulse-coded  serial  output.  The  output  of  the  encoder  is 
used  to  transfer  data  back  to  the  weapon  via  the  coil  driver  circuit  on  the 
CIU.  As  before,  this  series  of  pulses  is  coupled  between  the  player  glove 
and  the  weapon  handgrip  inductively.  The  laser  beam  of  the  weapon  is  in 
turn  modulated  on/off  to  output  the  same  pulse-coded  message,  this  time  on  a 
beam  of  infrared  light.  This  complete  sequence,  from  trigger  pull  detection 
to  laser  message  output  takes  from  2-5  milliseconds,  depending  on  the  buffer 
contents  at  the  time  of  a  trigger  pull  (how  much  of  the  buffer  data  is 
current).  When  the  laser  is  transmitting  the  message,  its  power  output  is 
monitored  by  circuitry  in  the  weapon-mounted  electronics.  If  the  output 
power  is  critically  low,  another  set  of  pulses  is  sent  from  the  weapon  to 
the  CIU  to  indicate  a  weapon  failure.  This  indication  of  a  weapon  failure 
is  then  passed  on  to  the  microcomputer  CIU  so  that  the  player  can  be  cued  of 
this  fact  and  a  bad  weapon  status  stored  in  the  player-pack  data  logger. 
The  time  of  transmission  of  the  pulse-coded  message  is  approximately  1.5 

mi  1 1 i seconds. 

A-5.4.2  Hit  Event.  When  a  player  is  "hit"  or  illuminated  by  a  laser,  the 
incoming  message  is  first  validated  to  insure  that  it  is  properly  encoded. 
This  validation  is  accomplished  by  identifying  a  predata  header  consisting 
of  a  pulse  pair  spaced  in  time  by  63  microseconds.  This  header  is  affixed 
to  the  message  data  during  the  time  of  transmission  from  the  firing  player. 
All  infrared  light  reaching  the  sensors  which  does  not  begin  with  this 

header  is  considered  garbled  (reflection)  and  is  ignored  by  the  CIU. 

Once  a  message  is  validated,  the  pulse  string  is  decoded  and 

stored  in  a  buffer  for  use  by  the  player  pack  microcomputer.  In  addition  to 


the  firer's  data  received  in  the  laser  message,  the  hit  location  on  the 
target  is  read  by  the  CIU  and  this  is  stored  in  the  receive  buffer.  The  CIU 
can  store  up  to  three  messages  at  a  time,  thus  circumventing  the  loss  of 
data  during  high  levels  of  weapon  engagement  activity.  Corresponding  to  the 
location  of  the  area  and  discrete  sensors,  the  following  is  a  list  of  bit 
locations  (these  can  be  also  used  to  discriminate  against  reflections  of  the 
laser  beam  due  to  the  characteristics  of  the  two  sensor  types  previously 
described): 


DISCRETE  AREA 


LOCATION 


X 

X 


X 

X 

X 

X 


Back 

Head 

Upper  Front 
Lower  Front 


The  outputs  of  the  sensor  signal  conditioners  are  hard-wired  to  a 
connector  which  plugs  into  the  playerpack.  As  noted  before,  the  micro¬ 
computer  uses  the  weapons  effects  subsystem  message  data  to  perform  real 
time  casualty  assessment  on  the  target  player. 

A-6.  PLAYER  PACK  PACKAGING. 


The  packaging  task  consisted  of  providing  a  suitable  enclosure, 
appropriate  harnessing  or  mounting,  and  adequate  power  supplies  for  the 
TNFS3  instrumentation.  An  extensive  packaging  effort  began  in  1979  to  test 
and  evaluate  designs  for  both  the  player  pack  and  the  battery  pack.  Several 
iterations  have  been  completed  with  significant  improvements  in  weight,  cost 
and  durability. 

A-6.1  Early  Testing  of  the  Player  Pack  Unit. 

The  player  pack  is  equipped  with  a  harness  engineered  for  comfort 
over  long  periods  of  use.  The  electronics  package  is  lightweight,  weather- 
tight  and  durable.  This  enclosure  allows  easy  access  to  the  electronics  for 
maintenance  while  providing  protection  against  water,  mud,  dirt,  etc. 
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A  market  survey  revealed  that  a  commercial  backpack  harness  and 
frame  suitable  for  the  player  pack  was  available.  The  harness  was  evaluated 
and  decisions  were  made  to  also  evaluate  a  soft  pack,  as  another  option. 
Environmental  simulations  and  tests  on  the  packs  were  completed  with  signi¬ 
ficant  differences  noted  in  the  internal  temperature  of  an  aluminum  enclo¬ 
sure  carried  in  each  of  the  packs.  The  goal  of  this  evaluation  was  to 
develop  a  backpack  which  was  insulated  from  solar  absorption  so  as  not  to 
overheat  the  electronic  components.  Temperature  testing  with  high  intensity 
heat  lamps  was  conducted  at  120°F  for  an  8-hour  period.  Results  indicated 
that  an  enclosure  with  active  components  consuming  10  watts  of  power  will 
reach  a  maximum  temperature  which  is  2Q-25°F  greater  than  the  external 
environment.  The  softpack  is  configured  to  allow  both  top  and  bottom  vent¬ 
ing,  as  shown  in  Figure  A- 1 2 ,  using  a  rough  weave  fabric  separated  from  the 
enclosure  by  a  sheet  of  lexan  to  meet  all  TNFS3  environmental  requirements. 
The  cost  of  the  chassis  and  softpack  is  less  than  earlier  versions  and  more 
easi ly  maintained. 

A-6.2  Meeting  Durability  Requirements. 

One  of  the  challenging  aspects  of  packaging  was  to  design  a  player 
pack  unit  which  was  both  lightweight  and  durable.  An  aluminum  enclosure, 
11.5  inches  by  3.5  inches  by  8.5  inches  (29.2  cm  by  8.9  cm  by  21.6  cm)  was 
designed  with  a  wall  thickness  of  1/16  inch  (1.6  mm)  and  seamless  welds  on 
all  corners.  It  is  painted  with  a  special  reflective  olive-drab  paint  to 
minimize  solar  heat  transfer.  System  modules  are  mounted  on  5-inch  by 
6.5-inch  (12.3  cm  by  16.5  cm)  shock  and  vibration  resistant  boards  which  are 
half  the  size  of  the  microcomputer  board.  Several  card  cage  designs  were 
tested  prior  to  selecting  a  framed  structure  which  is  durable  and  lighter 
than  previous  versions.  As  shown  in  Figure  A- 1 3 ,  the  enclosure  is  completed 
with  an  interface  panel  which  has  a  weather-tight  gasket  and  four  connectors 
to  interface  the  player  pack  with  external  devices.  This  packaging  method 
allows  easy  access  to  the  modules  for  maintenance  or  system  testing.  A 
completely  assembled  player  pack  weighs  approximately  nine  pounds  (4  kg). 
Field  tests  were  conducted  this  year  to  assess  the  weight  and  durability 
factors.  This  included  normal  field  exercises  such  as  rolling,  jumping,  and 
climbing.  The  results  to  date  indicate  that  the  packaging  effort  is 
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successful,  with  the  enclosure  capable  of  withstanding  the  force  of  a  250- 
pound  (117  kg)  player  falling  on  it. 

A-6.3  Selecting  a  OC  Power  Source. 

Since  the  player  pack  is  to  be  man  portable,  it  must  operate  from 
a  battery.  The  battery  must  be  lightweight  and  capable  of  powering  a  player 
pack  for  8  to  10  hours  of  continuous  use.  In  order  to  minimize  operational 
costs,  a  cost/benefit  analysis  was  performed  to  select  a  suitable  power 
source,  one  which  is  easy  to  operate  and  maintain. 

A-6.4  Battery  Packaging  and  Operation. 

A  silver-zinc  configuration  was  chosen  because  of  its  minimal 
weight  and  size,  high  capacity,  and  long  life  cycle  during  recharging.  The 
cells  are  connected  in  series,  forming  a  battery  pack  that  can  be  worn  by 
the  player  on  a  belt-clip  ammunition  pouch.  (See  Figure  A- 1 4 ) . 


Figure  A-14.  Battery  pack. 
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A  ruggedized  aluminum  container  was  developed  to  carry  11  of  the 
batteries,  allowing  it  to  be  easily  inserted  or  removed  for  maintenance. 
The  package  has  adequate  room  for  a  fuse,  a  posture  sensor,  and  1/4  inch 
(6.3  mm)  of  foam  which  cushions  the  batteries  from  external  damage.  A 
connector  interfaces  the  batteries  to  the  player  pack,  with  a  complete 
package  weighing  less  than  4  pounds  (1.8  kg.).  The  final  battery  selection 
is  still  open,  as  low  cost  primary  batteries  are  rapidly  being  developed  and 
a  final  decision  will  not  be  necessary  until  FY  1982. 

A- 7.  RF  SUBSYSTEM. 

The  RF  subsystem  is  comprised  of  transceivers  operating  at  1350  to 
1400  MHz  and  a  communications  interface  unit.  The  basic  function  of  the 
system  is  to  provide  a  communications  link  between  mabter  station  and 
players  in  the  TNFS3  scenario.  Operating  in  a  second  mode  known  as  trans¬ 
ponder,  the  RF  subsystem  employs  the  use  of  a  transponder  position  location 
card  and  is  used  to  obtain  range  measurements  between  players  and  fixed- 
location  repeater  towers.  For  a  more  detailed  explanation  of  the  trans¬ 
ponder  mode  of  operation,  please  refer  to  Appendix  A,  Section  A-8  of  this 
report. 

As  shown  in  Figure  A- 1 5 ,  the  RF  subsystem  has  three  main  compo¬ 
nents:  (1)  master  station  RF  unit,  (2)  repeater  tower,  and  (3)  player 
transceiver.  All  three  units  operate  at  the  same  frequency. 

The  RF  transceiver,  shown  in  Figure  A- 16,  is  used  at  the  master 
station,  repeater  towers,  and  player  packs.  It  provides  an  output  pulse  at 
1350  to  1400  MHz  *.  tuning  range)  approximately  2.0  microseconds  long  each 
time  a  command  to  transmit  is  given. 

The  transmit  and  other  control  lines  to  the  transceiver  operate  at 
standard  logic  levels,  thus  enabling  the  transceivers  to  be  easily  inter¬ 
faced  to  the  digital  electronics.  The  CIU  used  for  RF  communications, 
(Figure  A- 1 7 )  takes  cares  of  formatting  messages  which  are  transmitted  and 
decodes  incoming  pulses  from  the  transceiver.  Peak  power  output  of  the  RF 
units  is  20  watts  nominal. 
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A- 8.  TRANSPONDER  POSITION  LOCATION  CIRCUIT  (TPL). 

A-8. 1  Operational  Description. 

The  TPL  uses  a  time-of-fl ight/triangulation  method  of  determining 
position  location.  The  TPL  process  begins  by  having  the  player  pack  send 
unique  RF  signals  to  each  of  the  transponder  towers,  which  respond  by  send¬ 
ing  a  signal  back.  The  TPL  card  originating  the  signals  then  determines  the 
time  of  flight  to  each  of  the  towers.  This  time-of-fl ight  data  is  then 
passed  to  the  player  pack  microcomputer.  The  computer  knows  the  location  of 
all  the  transponder  towers  so  it  can  later  determine  its  own  location  based 
on  the  tower  distances. 

The  TPL  card  can  operate  in  four  modes:  repeater,  transponder, 
interrogator,  and  direct  range.  The  master  station  sends  a  message  that 
each  player  pack  decodes  and  then  tells  the  TPL  card  which  mode  to  be  in. 
The  towers  are  in  either  the  repeater  or  the  transponder  mode;  the  player 
packs  can  be  in  either  the  transponder,  the  interrogator,  or  the  direct 
range  mode. 

In  the  repeater  mode,  the  TPL  card  retransmits  every  message  it 
hears.  In  the  transponder  mode,  the  TPL  card  watches  for  a  specific  message 
(its  own  ID  message)  and  waits  for  a  fixed  delay,  and  then  retransmits  that 
message.  In  the  interrogator  mode,  the  TPL  card  sends  out  the  tower  ID  and 
starts  a  timer.  When  the  tower  responds  with  that  ID,  the  TPL  card  turns 
off  the  timer  and  stores  the  elapsed  time  (minus  the  fixed  delay  time).  The 
direct  range  mode  is  the  same  as  the  interrogator  mode  except  the  ID  that  is 
transmitted  is  one  of  another  player  rather  than  one  of  a  tower.  This  mode 
is  useful  in  finding  the  range  between  two  players  who  are  not  within  range 
of  at  least  four  towers  (such  as  within  a  building).  The  direct  range  mode 
is  also  useful  as  a  check  to  determine  if  two  players  are  in  line  of  sight 
with  each  other. 

The  position  location  (PL)  cycle  begins  with  a  start  message  from 
the  master  station,  simultaneously  starting  both  the  player  packs  and  the 
towers.  The  players  are  told  which  transponder  (either  towers  or  other 
players)  they  should  interrogate  and  how  long  the  PL  cycle  will  last.  The 
next  message  from  the  master  station  commands  the  specified  players  and 
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towers  to  begin  the  PL  cycle.  The  towers  then  switch  (under  control  of  the 
tower's  microcomputer)  from  the  normal  repeater  mode  to  the  transponder  mode 
and  stay  in  that  mode  until  the  PL  cycle  is  over  (the  TPL  time-out  indicates 
the  end  of  the  cycle).  The  players  involved  in  the  PL  cycle  enable  their 
TPL  to  begin  its  interrogation  mode  while  the  other  time  tells  the  TPL 
circuit  when  the  PL  cycle  is  over.  The  player  pack  is  in  the  transponder 
mode  until  it  is  time  to  be  an  interrogator,  it  then  interrogates  the 
assigned  towers  (or  players).  After  it  has  completed  its  interrogations  the 
player  pack  goes  back  to  being  a  transponder.  When  the  PL  cycle  is  over, 
the  player  pack  stays  in  the  transponder  mode  and  waits  for  the  next  master 
station  message. 

A -8.2  Functional  Description. 

The  heart  of  the  TPL  circuit  is  the  microprocessor,  shown  in 
Figure  A- 1 8,  an  8748  single-chip  controller.  The  8748  has  built-in  ROM  and 
RAM  providing  a  very  efficient,  low  cost  design.  The  8748  can  be  controlled 
to  handle  several  of  the  board's  functions  including:  power  cycling,  input 
and  output  to  the  player-pack  computer,  storing  the  IDs  of  the  transponders 
to  be  interrogated,  storing  the  range  data,  and  controlling  the  analog-to- 
digital  converter. 

The  range  counter  block  is  made  up  of  a  75-MHz  clock  and  several 
high  speed  counters  and  gates  (ECL  and  TTL).  The  range  clock  counts  the 
time-of-f 1 ight  to  and  from  the  transponder  with  6.6-nanosecond  resolution. 
The  data  collected  by  the  range  counter  is  stored  in  the  microprocessor. 
The  interface  control  block  is  made  up  of  gates  and  multiplexers.  The  block 
handles  the  data  traffic  between  the  TPL  card  and  the  player  pack  micro¬ 
computer. 

The  ID  verify  block  handles  the  recognition  of  any  ID  the  TPL 
board  might  be  looking  for.  The  TPL  card  must  be  able  to  recognize  its  own 
ID  and  it  also  must  be  able  to  recognize  the  ID  of  any  transponders  it  is 
interrogating.  In  order  to  be  recognized,  the  ID  is  loaded  into  the  ID 
verify  block  by  the  8748  microprocessor,  the  TPL  card  then  watches  the 
received  pulse  input  for  the  required  ID.  When  this  ID  is  seen,  the  ID 
verify  block  sends  a  stop-count  signal  to  the  range  counter  indicating  that 
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the  measurement  of  time-of-f 1 ight  should  cease.  The  analog-to-digi tal  (A/D) 
block  is  used  to  digitize  the  signal  strength  of  the  return  pulses.  The  A/D 
is  controlled  by  the  8748  microprocessor,  which  tells  the  A/D  to  sample  the 
return  pulses  and  then  store  the  data.  The  data  are  later  used  by  the 
player  pack  computer  to  correct  for  range  errors  that  are  caused  by  fluctua¬ 
tions  in  signal  strength. 

A-8.3  Circuit  Description. 

The  TPL  circuit  was  designed  around  several  constraints.  The 
player  pack  is  man  portable  so  it  must  be  as  compact  as  possible.  This 
constraint  leads  to  the  requirement  that  the  TPL  circuit  must  fit  on  a 
single  small  card  (approximately  6  by  7  inches).  The  man  portable 
constraint  also  requires  that  the  power  consumption  of  all  the  circuits  be 
low.  The  high  accuracy  constraint  of  the  TNFS3  requirements  dictates  the 
use  of  high  speed  circuitry  on  the  TPL  card.  These  various  constraints 
produced  many  novel  design  approaches  in  order  to  get  a  complex  but  small, 
low  power  but  fast,  TPL  design.  The  end  result  is  a  circuit  that  combines 
the  density  of  large  scale  integration  (LSI)  components  with  the  the  speed 
of  emitter-coupled  logic  (ECL),  and  transistor-transistor  logic  (TTL)  compo¬ 
nents  with  the  low  power  consumption  of  CMOS  and  low-power  Schottkey  com¬ 
ponents. 

A-9.  KEY  ENTRY  AND  DISPLAY  UNIT. 

The  purpose  of  the  key  entry  and  display  unit  (KENDU)  is  to 
provide  means  for  a  human  operator  to  easily  communicate  with  the  player 
initializer  (PI)  or  a  player  pack.  The  KENDU  is  designed  to  interface  over 
a  non-standard  serial  link.  This  serial  link  is  similar  to  RS-232-C  but  the 
EIA  levels  (±12  volts)  are  not  used.  In-line  translating  modules  are  used 
so  that  the  KENDU  can  communicate  over  standard  RS-232  type  interfaces  with 
devices  such  as  terminals  and  printers. 

The  KENDU  is  designed  to  operate  in  the  hostile  and  demanding 
environment  expected  to  be  part  of  the  TNFS3  scenario.  The  unitized  and 
environmentally  sealed  keyboard  surface,  impervious  to  liquids,  dust,  or 
mud,  is  combined  with  the  ruggedized  packaging  concept,  making  this  device 
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ideal  as  an  all  purpose  human  interface  to  the  TNFS3  test  instrumentation. 
Another  desirable  feature  is  high  immunity  to  RF  noise,  implemented  by  using 
CMOS  components  in  this  design. 

The  KENDU  keyboard  is  equipped  with  40  keys  and  a  function  key 
which  allows  the  operator  to  select  and  transmit  up  to  78  distinct  charac¬ 
ters  or  control  characters.  The  KENDU  character  generator  allows  for  64 
different  characters  to  be  displayed,  as  shown  in  Figure  A- 1 9 . 

The  liquid  crystal  display  (LCD)  module  is  an  alphanumeric  5x7  dot 
matrix  capable  of  displaying  32  characters  on  two  lines.  The  LCD  display 
provides  excellent  viewability  of  the  1/4-inch  characters  under  any  lighting 
conditions.  In  poor  lighting  conditions,  the  operator  can,  by  means  of  a 
switch,  backlight  the  display. 

The  KENDU  is  designed  to  operate  from  a  single  6  to  30-volt  exter¬ 
nal  power  source.  Power  consumption  is  minimized  since  all  circuitry  is 
implemented  using  CMOS  technology. 

A- 10  PLAYER  PACK  SOFTWARE  DEVELOPMENT. 

Software  is  as  important  to  modern  instrumentation  as  hardware. 
It  is  through  the  software  that  the  hardware  is  able  to  perform  in  a 
meaningful  way.  In  other  words,  the  instrumentation  is  "software  driven." 
This  applies  equally  to  modern  distributed  instrumentation  as  well  as  to  the 
older  centralized  architectures. 

Software  typically  accounts  for  75  percent  or  more  of  the  costs 
incurred  in  an  instrumentation  system,  and  nearly  all  of  the  recurring  costs 
are  attributable  to  software  generation.  Several  things  have  been  done  in 
defining  the  TNFS3  instrumentation  that  minimize  both  the  initial  and  the 
recurring  costs  of  software  development.  First,  whenever  possible,  software 
supplied  by  the  computer  vendor  is  used.  Second,  all  software  is  produced 
using  modular,  top-down  structured  programming  techniques.  This  makes  the 
software  traceable,  flexible,  and  maintainable.  It  can  be  easily  and 
quickly  modified  as  the  situation  demands.  Finally,  the  computers  used  to 
form  the  master  station  and  the  player  packs  were  chosen  because  they  share 
a  common  instruction  set.  This  commonality  is  true  at  both  the  coding  and 
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the  object  level.  This  commonality  is  unique  and  vastly  reduces  the  total 
programming  burden  as  well  as  providing  module  transportability  between  the 
master  station  and  the  player  packs.  This  level  of  transportability  would 
be  only  partially  achieveable  by  use  of  high  order  languages  if  not  for  this 
compatibility. 

A-10.1  Statement  of  the  Requirement. 

All  of  the  requirements  placed  on  the  TNFS3  instrumentation  as  a 
whole,  and  implemented  in  the  present  hardware  design,  apply  equally  to  the 
software.  Fortunately,  the  distributed  architecture  of  the  TNFS3  instru¬ 
mentation  vastly  simplifies  the  software  and,  consequently,  reduces  the 
associated  risks. 

The  player  pack  software  must  handle  the  real-time  data  processing 
requirements  of  a  single  player  and  must  be  able  to  adapt  quickly  to  changes 
in  the  player's  role  in  the  test.  A  change  in  role  might  be  simply  to 
change  his  vulnerability  (i.e.,  body  armor,  etc.)  or  his  marksmanship  in 
order  to  evaluate  any  resultant  improvements.  On  the  other  hand,  such  a 
change  could  involve  new  or  different  hardware  modules  along  with  the  soft¬ 
ware  modules  for  handling  them.  In  short,  the  software  must  be  highly 
flexible.  At  the  same  time,  however,  it  must  also  be  highly  reliable. 

Real-time  processing  in  a  test  environment  means  a  great  deal  more 
than  simply  speed.  The  processes  in  the  computer  must  adapt  to  handle 
incoming  player  data  on  a  priority  basis.  For  example,  position  location 
calculation  is  a  real-time  process,  but  incoming  weapon  engagement  data  must 
cause  the  Real-Time  Casualty  Assessment  (RTCA)  process  to  be  invoked  immedi¬ 
ately.  If  the  player  is  assessed  as  a  casualty,  his  position  is  of  no 
further  interest.  On  the  other  hand,  if  RTCA  is  already  in  progress  when 
additional  engagement  data  arrives,  a  new  RTCA  process  must  be  started.  In 
this  situation,  the  RTCA  processes  should  run  concurrently  since  either 
could  result  in  a  "kill."  Furthermore,  the  position  location  process  that 
was  interrupted  must  not  be  allowed  to  totally  languish  since  the  player  may 
well  be  left  "alive."  Consequently,  there  are  now  three  processes  that 
should  be  executing  concurrently.  There  are  other  real-time  processes  that 
must  be  allowed  to  execute  in  addition  to  RTCA  and  position  location.  Data 
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logging,  time-keeping,  built-in  test,  RF  communications,  and  weapon  firing 
are  examples  of  some  of  these.  Thus  a  large  number  of  real-time  processes 
compete  simultaneously  for  the  resources  of  the  player  pack  computer. 


Finally,  the  software  must  be  highly  modular  in  order  to  take 
maximum  advantage  of  the  modular  architecture  of  the  player  pack  hardware. 
This  combination  of  modularity  in  both  hardware  and  software  results  in 
maximum  flexibility. 

This  morass  of  apparently  irreconcilable  requirements  is  easily 
handled  by  a  well  known  structure  from  minicomputer  software  known  generi- 
cally  as  a  "multi-tasking  operating  system."  This  single  concept,  when 
fully  implemented,  provides  the  procedural,  functional,  and  operational 
capabilities  identified  as  requirements  for  the  instrumentation  in  the 
scoping  phase  of  the  program. 

The  operating  system  structure  automatically  provides  the  process 
prioritization  discussed  above.  It  isolates  the  player-related  computa¬ 
tional  tasks  from  I/O  processes  thereby  further  simplifying  the  production 
of  the  tasks  and  enhancing  the  overall  reliability  of  the  total  software 
package.  Device  drivers  appear  as  "plug  in"  modules  rather  than  as  imbedded 
portions  of  the  system.  These  features  combine  to  provide  a  very  responsive 
system  that  is  quickly  and  easily  modified  and  still  maintains  a  high  level 
of  reliability. 

A-10.2  Functional  Description. 

The  player  software  consists  of  three  major  modular  elements:  the 
operating  system  kernel,  the  requisite  device  drivers,  and  the  player 
related  processes  called  tasks.  To  change  a  player's  role  in  a  test,  it  is 
necessary  to  change  only  the  set  of  player  tasks.  To  change  player  type, 
the  tasks  are  changed  and  probably  the  player  pack  hardware  is  changed.  In 
this  case,  new  device  drivers  are  also  supplied.  In  any  case,  each  of  the 
major  software  divisions  is  highly  modular,  making  such  changes  quite 
simple.  The  primary  goal  of  the  software  modularity  is  to  maintain  sim¬ 
plicity.  For  example:  tasks  need  not  be  concerned  with  any  I/O  processing. 
When  a  task  must  input  or  output  data,  it  simply  requests  the  specified 
process  of  the  operating  system  and  relinquishes  control  of  the  CPU.  The 
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operating  system  and  the  device  drivers  handle  the  data  transfer.  Likewise, 
a  device  driver  need  have  no  concern  for  the  ongoing  computational  pro¬ 
cesses.  It  merely  transfers  data  as  requested  and  then  releases  control  of 
the  CPU.  All  data  transfers  are  interrupt  driven  in  order  to  maximize  total 
system  throughput. 

A- 10.2.1  The  Operating  System  Kernel.  This  kernel  consists  of  six  modular 
subsections:  the  memory  allocation  supervisor,  the  task  control  supervisor, 
the  task  scheduler,  the  I/O  supervisor,  the  file  manager,  and  a  miscella¬ 
neous  services  module  (see  Figure  A-20). 

The  memory  allocation  supervisor  keeps  track  of  the  size  and 
location  of  blocks  of  memory  that  are  currently  not  in  use  and  hence  avail¬ 
able  to  any  process  that  needs  additional  memory.  This  dynamic  allocation 
feature  allows  the  player  pack  to  work  with  much  less  physical  memory  than 
would  be  required  without  it.  This  in  turn  reduces  the  size,  weight,  and 
power  requirements  of  the  player  pack. 

The  task  control  supervisor  provides  the  task  coordination 
services  needed  in  a  multi-task  environment.  Through  this  supervisor  a  task 
can:  halt  its  execution,  halt  its  execution  for  a  specified  time,  halt  its 
execution  until  a  specified  I/O  process  completes,  activate  another  task 
which  is  halted,  initiate  execution  of  another  task,  schedule  execution  of  a 
task  at  some  specified  future  time,  terminate  permanently  its  own  execution, 
and  other  functions  necessary  for  smooth  interactive  process  coordination. 
This  module  maintains  the  prioritized  lists  of  tasks  which  are  eligible  for 
execution  for  the  task  scheduler. 

The  task  scheduler  is  responsible  for  selecting  the  currently  most 
important  pending  task  and  executing  it.  A  round-robin  algorithm  is  used  to 
insure  that  low  priority  tasks  don't  get  entirely  "locked  out."  The 
scheduler  is  invoked  every  50  milliseconds  to  prevent  a  task  from  "hogging" 
the  computer  and  to  provide  concurrent  processing.  It  is  also  invoked  any 
time  the  executing  task  causes  itself  to  be  suspended,  ( i . e .  ,  "halt  task" 
supervisor  call,  I/O,  etc.). 


The  I/O  supervisor  is  responsible  for  establishing  and  maintaining 
logical  pathways  for  data  transfers  between  tasks  and  peripheral  devices. 


TASK  SCHEDULER 
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Tasks  communicate  with  "logical"  devices  through  the  I/O  supervisor  rather 
than  directly  with  the  hardware.  This  assures  that  the  data  transfers 
always  occur  properly  and  relieves  the  task  of  the  burden  of  manipulating 
the  hardware.  Furthermore,  the  means  of  communication  is  identical  for  all 
devices.  This  further  simplifies  the  software  production  effort. 

The  file  manager  is  a  subsection  of  the  I/O  supervisor.  Its  role 
is  to  provide  tasks  with  access  to  data  stored  in  the  magnetic  bubble  memory 
mass  storage  unit  in  a  standardized  manner.  In  fact,  access  to  stored  data 
is  processed  by  the  task  in  precisely  the  same  way  as  access  to  external 
data  via  hardware  is  handled. 

The  miscellaneous  services  module  is  a  catch-all  collection  of 
commonly  required  subroutines.  It  provides  binary  to  ASCII  and  ASCII  to 
binary  conversions,  access  to  the  real-time  clock,  and  intertask  communi¬ 
cation,  among  others. 

A- 10.2.2  Device  Drivers.  Device  drivers  are  software  modules  dedicated  to 
transferring  data  to  and  from  hardware.  They  control  the  operation  of  the 
device  in  a  manner  consistent  with  its  intended  function.  Each  device  in 
the  player  pack  has  an  associated  device  driver  and  only  those  drivers 
needed  are  included  in  the  total  software  package  for  the  player. 

Device  drivers  interface  to  the  I/O  supervisor  through  a  rigidly 
defined  software  protocol  to  insure  proper  interaction  between  the  operating 
system  and  the  hardware.  They  service  the  interrupts  provided  by  the  hard¬ 
ware  in  a  specified  manner  designed  to  maintain  maximum  process  integrity. 

The  protocols  defined  for  the  device  drivers  are  simple  and  short 
and  allow  such  modules  to  be  produced  very  quickly  and  easily. 

A-10.2.3  Tasks.  The  collection  bf  tasks  installed  in  the  player  pack, 
shown  in  Figure  A-21 ,  define  how  the  real-time  player  interaction  data  will 
be  processed.  Tasks  call  upon  the  operating  system  in  a  simple,  consistent 
manner  to  request  commonly  needed  services,  drastically  simplifying  their 
production. 

The  tasks  establish  the  "personal ity"  of  the  player  pack.  There 
are  no  restrictions  placed  on  the  function  of  the  tasks  by  the  operating 
system. 
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TASK  SCHEDULER 


THE  BDM  CORPORATION 


A/D 

AMSAA 

APU 

Bit 

Buffer 

Byte 

CDEC 

CIU 

CMOS 

CONUS 

CPU 

CRU 


APPENDIX  B 
GLOSSARY 

Analog  to  Digital.  An  electronic  means  of  converting  a 
voltage  continuous  with  respect  to  time  into  a  number 
represented  by  a  discrete  set  of  voltage  states.  A  con¬ 
tinuous  voltage  is  converted  into  a  discrete  digital  word 
or  number. 

Army  Materials  Systems  Analysis  Activity 
Arithmetic  Processing  Unit.  Provides  floating  point 
arithmetic,  trigonometric  functions,  etc.,  on  a  single 
integrated  circuit.  Very  high  speed. 

Unit  of  information  equal  to  one  binary  decision,  repre¬ 
sented  by  a  one  or  a  zero. 

A  sequence  of  locations  in  the  computer's  memory  which  are 
used  for  temporary  storage  of  data.  Used  heavily  when 
transferring  data  from  the  computer  to  an  external  device. 
8-bit  packet  of  digital  computer  data. 

Combat  Development  Experimentation  Command. 

Communications  Interface  Unit.  A  module  in  the  TNFS3 
player  pack  which  handles  data  conversion  for  both  the 
laser  weapon  simulator  and  RF  communications. 

Complementary  Metal  Oxide  Semiconductor.  Extremely  low- 
power  technology.  Only  a  limited  number  of  functional 
part  types  are  available.  Very  slow  operation  compared  to 
other  technologies. 

Continental  United  States. 

Central  Processing  Unit.  In  a  microcomputer  this  refers 
to  the  microprocessor  component. 

Communications  Register  Unit.  A  serial  data  link  used  by 
the  9900  family  of  computers  to  communicate  with  devices 
external  to  the  CPU. 


8-1 


Appendix  B 
OMA 


DMAC 


DNA 

DSR 


DXIO 

ECS 


EPROM 

EUCOM 

GFE 

GPS/ 

NAVSTAR 

ID 

IDF 


ILS 


Glossary  (Continued) 

Direct  Memory  Access.  The  process  of  transferring  infor¬ 
mation  from  one  area  of  a  computer  to  another  without 
intervention  by  the  CPU.  It  is  orders  of  magnitude  faster 
than  CPU-controlled  transfers. 

Direct  Memory  Access  Controller.  A  single  integrated 
circuit  which,  once  initialized  by  the  CPU,  controls  the 
DMA  process. 

Defense  Nuclear  Agency. 

Device  Service  Routine.  A  software  routine  used  to  inter¬ 
face  a  device  to  the  ECS  software.  An  example  of  a  DSR 
would  be  the  software  needed  to  transfer  data  from  the 
computer  to  an  external  device  such  as  the  data  logger. 
Operating  system  for  the  TI990  Minicomputer. 

Executive  Control  System.  The  player  pack  microcomputer, 
including  hardware  and  software,  exclusive  of  the  func¬ 
tional  hardware  modules. 

Eraseable  Programmable  Read  Only  Memory. 

European  Command. 

Government  Furnished  Equipment. 

Global  Positioning  System.  A  position  location  system 
based  on  the  use  of  synchronous  satellites. 

Identification  Code.  Used  to  identify  players,  weapons, 
and  weapon  types. 

Indirect  Fire.  Generic  term  referring  to  all  military 
weapons  except  those  used  in  a  point-to-point  mode,  such 
as  rifles.  Examples:  mortars,  artillery,  grenades, 
missiles,  etc.  Usually  with  explosive  rounds. 

International  Laser  Systems,  Orlando,  Florida.  Awarded 
contract  by  DNA  for  the  Weapons  Effects  system. 
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I/O 

Interrupt  - 

LOS 

LORAN 

Micro¬ 
processor  - 

MILES 

NMOS 

Operating 

System 


O&M 

PL 


Input/Output.  Refers  to  the  generic  data  transfer  pro¬ 
cess.  Usually  implies  communications  between  a  computer 
and  its  peripherals. 

A  signal  from  a  device  outside  the  microprocessor  which 
tells  the  microprocessor  that  the  device  is  requesting 
some  sort  of  service. 

Line  of  Sight.  Refers  to  weapons  which  are  usually 
sighted  on  the  target  (rifles,  etc.). 

Instrumentation  developed  for  the  purpose  of  determining 
time-correlated  fixed  and  dynamic  position  locations  of 
players. 

A  one-chip  processing  unit  which  contains  an  arithmetic/ 
logic  unit,  temporary  storage  registers,  and  timing  and 
control  circuitry.  Usually  has  a  word  length  of  16  bits 
or  less  and  an  addressing  capability  of  65K  bytes  or  less. 
Average  instruction  execution  time  is  on  the  order  of  1  to 
10  microseconds. 

Multiple  Integrated  Laser  Engagement  System,  manufactured 
by  XEROX  for  TRADOC.  A  weapons  training  device. 

N-channel  Metal  Oxide  Semiconductor.  NMOS  is  a  logic 
family  which  is  used  primarily  in  memory  applications. 
This  logic  family  has  a  fairly  high  density  while  using 
relatively  low  amounts  of  power. 

The  collection  of  software  modules  which  control  the 
allocation  of  the  resources  of  the  CPU  and  the  external 
devices. 

Operations  and  Maintenance. 

Position  Location. 
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PROM 

PSI 

RAM 


Real 'Time 
Clock 


Programmable  Read  Only  Memory.  Memory  which  has  the 
ability  to  be  user  programmed.  Otherwise,  same  as  ROM. 
Programmable  Systems  Interface  provides  interrupts,  I/O 
ports  and  interval  timer  for  the  9900  System. 

Random  Access  Memory.  A  memory  which  can  be  read  from  or 
written  to  in  approximately  the  same  amount  of  time.  Used 
to  store  data  which  must  be  changed. 

Hardware  external  to  the  microprocessor  which  interrupts 
the  processor  on  a  periodic  basis.  The  real-time  clock 
can  be  used  by  the  computer's  operating  system  to 
implement  such  functions  as  time  slicing  and  time  of  day. 


RFCIU 

ROM 


RTCA 


Sub¬ 

routine 


Task 


Radio  Frequency  Communications  Interface  Unit. 

Read  Only  Memory.  A  memory  that  is  used  for  storage  of 
fixed  programs  or  data.  Retains  its  information  when 
power  is  turned  off.  Contents  cannot  be  altered.  Con¬ 
tents  set  during  manufacturing. 

Real-Time  Casualty  Assessment.  A  computer  algorithm  which 
determines  the  probability  that  an  engaged  player  has  been 
ki lied. 

A  section  of  code  which  is  used  frequently  can  be  placed 
into  a  form  such  that  any  program  which  needs  the  service 
can  "call"  the  subroutine.  The  use  of  subroutines  can 
result  in  a  considerable  savings  in  memory  requirements. 

A  computer  program  which  performs  some  computational 
function.  An  example  of  a  task  in  the  TNFS2  player  pack 
application  would  be  the  real-time  casualty  assessment 
calculation. 
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Task 

Scheduler  - 


TI 

TNFS3 

TRADOC 

TSEM 

TTL 

USAFE 


The  software  module  which  determines  which  tasks  in  the 
system  should  become  active  and  at  which  priority  they 
should  execute. 

Texas  Instruments. 

Theater  Nuclear  Force  Survivability,  Security,  and  Safety. 
U.S.  Training  and  Doctrine  Command. 

Transportation  Safeguards  Effectiveness  Model. 
Transistor-Transistor  Logic.  A  logic  family  characterized 
by  its  input/output  features.  Very  commonly  used. 

United  States  Air  Force  in  Europe. 


VEGA  -  VEGA  Precision,  Vienna,  Virginia 
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